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ABSTRACT 



A graphical user interface for mapping and accessing objects 
in data stores is disclosed. A user may define a mapping 
between object schema and data store schema by use of a 
high level language, Schema Mapping Definition Language 
(SMDL), which is data store independent, object oriented 
language independent, and extensible. The user may either 
write SMDL directly or generate SMDL through the use of 
a graphical user interface Smart Schema whose graphical 
semantics support the SMDL semantics. A Schema Mapping 
Internal Representation (SMIR) containing representations 
of the object schema, the data store schema, and the mapping 
of the object schema and the data store schema is generated 
by an SMDL Parser from the SMDL. The SMIR is repre- 
sented such that it may be accessible by both development 
interfaces and run-time environments. It supports the access- 
ing of the mapping information given either the object 
schema or data store schema such that the data store schema 
may be accessed from the object schema, and the object 
schema may be accessed from the data store schema. An 
SMDL Generator may be used to generate the SMDL from 
the SMIR. The SMIR, SMDL Generator, SMDL Parser, and 
SMDL may be registered in a Data Store Manager (DSM) 
having a single, uniform, object oriented application pro- 
graming interface for accessing one or more data stores, 
regardless of the type of data store. The DSM may use the 
SMIR to access objects from a data store. The SMIR may 
also be used by a run-time environment to provide direct 
access of objects from a data store, or it may be used by 
various Code Generators to generate an object oriented 
programing language for providing direct access to objects 
from a data store. 

6 Claims, 14 Drawing Sheets 
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SYSTEM AND METHOD FOR PROVIDING A have. A unique object may be refeired to as an object 

GRAPHICAL USER INTERFACE FOR instance ox an instance. 

MAPPING AND ACCESSING OBJECTS IN An object class describes a group of objects with similar 

DATA STORES properties (attributes), common behavior (operations), com- 

PROSS ppttrppmpr T n ppt atrti 5 mon relationshl P s to otner objects, and common semantics. 

CROSS-Rmi^CTTO RELATED Qbjects in a dass haye me ^ ^ 

Arri^uAi turn patterns. The objects derive their individuaHty from differ- 

Application Ser. No. 08/276,382, filed concurrently here- ences in the attribute values and relationship to other objects, 

with on Jul 18, 1994 for A SYSTEM AND METHOD FOR The class defines the object's data structure and methods to 

MAPPING AND ACCESSING OBJECTS IN DATA 10 access that data structure. Methods and data structure are 

STORES (IBM Docket ST9-94-016), currently co-pending, shared among objects of the same class. An object knows its 

and assigned to the same assignee as the present invention. c ^ ass the methods it possesses as a member of the class. 

Appliation Ser. No. 08/276,747, filed concurrently here- Common definitions such as class name and attribute names 

with on Jul. 18, 1994 for A SYSTEM AND METHOD FOR ? c storcd oncc J* 1 * class > iatflcr man oncc ob j cc t 

PROVIDING A HIGH LEVEL LANGUAGE FOR MAP- 15 instance - Operations may be written once for a class so that 

PING AND ACCESSING OBJECTS IN DATA STORES ^ ob j ccts m mc class benefit from code reuse. 

(IBM Docket ST9-94-018), currently co-pending, and ^ attribute is a data value, not an object, held by. the 

assigned to the same assignee as the present invention. objects in a class. Each attribute has a value for each object 

The foregoing copending applications are incorporated , n instance * Differe ** object instances may have the same or 

herein by reference different values for a given attribute. Each attribute name is 

A portion of the Disclosure of this patent document ^ * ^ * ^ ^ ^ 
contains material which is subject to copyright protection. 

The copyright owner has no objection to the facsimile A link is a relationship between object instances, a tuple 

reproduction by anyone of the patent document or the patent 25 °i ordered m of ^J 0 * instances. A link is also an instance 

disclosure, as it appears in the Patent and Trademark Office of an ^ sodatl011 - ^ association is a group of links with 

patent file or records, but otherwise reserves all copyright coiranon structure and common semantics. All the links in 

rights whatsoever. 311 associatl0n connect objects from the same classes. An 

association describes a set of potential links in the same way 

BACKGROUND OF THE INVENTION 3Q that a class describes a set of potential objects. Associations 

1. Field of the Invention ^ C inherejltl y bidirectional and can be traversed in either 
* . , L . ■ . direction. Associations are often implemented in various 

This invention relates to object oriented systems and data object oricnted ^^^^^ languages as pointers from one 

store systems, and more particularly to mapping between object to another. A pointer is an attribute in one object that 

object schema and data store schema. contains ^ cxpUcit reference to ^ 

2. Description of the Related Art 35 As an attribute is a property of objects in a class, a link 
The data processing industry and its customers have made attribute is a property of the links in an association. Each link 

considerable investments in conventional data store attribute has a value for each link. Many-to-many associa- 

technology, including relational databases, hierarchial tions are the rationale for link attributes. 

databases flat file databases, and network databases. Generalization and inheritance are powerful abstractions 

ftesendy mere^ 40 for sharing similaritics dasscs ^ 

lying relational databases is the predominant conventional differences. Generalization is the relationship between a 

method of storing data in databases. ckss and one or more refined versions of it The class being 

Object oriented technology has also gained wide accep- refined is called the superclass, and each refined version is 

tance due to its strengths inreal world modeling, modularity, 45 called a subclass. Attributes and operations common to a 

reuse, distributed computing, client/server computing, and group of subclasses are attached to the superclass and stared 

graphical user interfaces. by each subclass. Each subclass is said to inherit the features 

However, the object model underlying object oriented. of its superclass. Generalization and inheritance are transi- 

technology and the data model underlying conventional data tive across an arbitrary number of levels. Hie terms ancestor 

stores are different, and a way is needed to provide the 50 and descendent refer to generalization of classes across 

advantages of object oriented technology while preserving multiple levels. An instance of a subclass is simultaneously 

the substantial investment in conventional data store tech- an instance of all of its ancestor classes. The state of an 

nology. instance includes a value for every attribute of every ances- 

An object model captures the structure of a system by tor class. Any operation on any ancestor class can be applied 

representing the objects in the system, the relationships 55 t0 an instance. 

between those objects, and the attributes and operations that Generalization and inheritance arc fundamental concepts 

characterize each class of objects. The purpose of object in object-oriented languages, and these concepts do not exist 

modeling is to describe objects, and an object is simply in conventional languages and databases. During conceptual 

something that has a meaningful behavior in an application modeling, generalization enables a developer to organize 

context. An object has data, the value of which represent the 60 classes into a hierarchial structure based on their similarities 

object's state. The behavior that an object exhibits is pro- and differences. During implementation, inheritance facili- 

yided by operations on that data, and this behavior may be tates code reuse. Generalization refers to the relationship 

invoked by other objects sending messages. These opera- among classes; inheritance refers to the mechanism of 

tions are implemented as procedures called methods. All obtaining attributes and operations using the generalization 

objects have identity and are distinguishable. The term 65 structure. 

identity means that an object is distinguishable by its inher- The object schema may be viewed as consisting of a set 

ent existence and not by descriptive properties that it may of object classes, wherein each object class consists of a set 
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of object instances, wherein each object instance contains a by its location. The order of rows is not significant. There are 

set of attributes, and wherein object classes and object no duplicate rows. The domain for every attribute must 

instances may be linked in relationships. consist of atomic value; there are no repeating groups. If the 

Instead of the above object model conventional data store value for a particular field is unknown or does not apply, 
technology uses a data model in which a data model (also 5 then the relational mod assigns a null value, 
known as an information model or conceptual model) is Tables contain information about entities or the relation- 
designed by modeling the world that the application is to ship between entities. Each tuple refers to a different entity, 
support Then the data model is transformed into a particular and each attribute value in the tuple supplies information 
database design by applying one or more standard about one characteristic of that entity. Each table must have 
transforms, for example, normalization which requires that 10 a column or group of columns that serve to uniquely identify 
data of an entity belong to that entity only. the tuple. 

The data models offered by conventional database tech- Each set of attributes that uniquely identifies each tuple is 

nology include flat files, indexed rile systems, network data referred to as a candidate key. There may be multiple 

model, hierarchial data model, and the relational model. candidate keys in a relation, but one must be designated as 

The flat file model provides a simple means of storing data 15 the primary key. Foreign keys are used to define a link to 

in records which may be accessed according to the data another table. A foreign key is a key taken from another table 

therein; however, it provides no independence between the to create a linking value to serve as a means of navigation 

data and applications thus requiring the applications to be from one table to the other table. A table may contain as 

modified if the flat file design is changed. Aflat file data store many foreign keys as links it requires to relate it to other 

schema consists of records composed of fields. 20 tables with which it has relationships. 

Indexed file systems provide fixed-length records com- The process of determining the correct location and 

posed of data fields of various types, and indexes to more function for each attribute to correctly formulate the rela- 

quickly locate records satisfying constraints on field values. tional schema is called normalization. Normalization 

An indexed file system data store schema consists of records decomposes incorrectly constructed relations into multiple 

composed of fields wherein certain fields may be keys correctly normalized relations. 

(indexes). The relational model requires that all tables must be in at 

A network data model provides fixed-length records com- least first normal form. To be in first normal form, a relation 

posed of data fields of various types and indexes similar to must have domains consisting only of atomic values for each 

the indexed file systems. In addition, the network data model 3Q attribute. Repeating sets of attributes and multi-valued 

provides record identifiers and link fields which may be used attributes are not allowed. Optionally, the relational model 

to connect records together for fast direct access. Hie may be subject to additional higher forms of normalization 

network data model also uses pointer structures to encode a based on functional dependency, Lc., the reliance of an 

network structure or relationship of records. A network data attribute or group of attributes on another attribute or group 

store schema consists a set of network structures of records, 35 of attributes for its value. 

wherein each record is composed of fields, wherein certain ^ relational schema may be viewed as consisting of a 

fields may be keys (indexes) and certain fields may be links set of tables, wherein each table consists of columns and 

to other records (link fields). rows, and wherem relation between table are specified by 

The hierarchial data model, similar to the network data primary keys and foreign keys, 

model, provides fixed-length records composed of data ^ view of the above differences between object oriented 

SSI l^°Ut » rCC ° rd f n K bfierS technology and data store technology, there is a need for a 

^nl^n^' h , 0WCVCr ' ^5"^ method of, and apparatus for, allowing a user to access a 

7t<^* tl TT I k-° ^1 ? f c i daUo f m P conventional data store from an object oriented application, 

of records to tree structures. A hierarchial data store schema - , . , , . « . _ ,_. _ . 

consists of a set of tree structures of segments (each tree « *™ W ° ^bove differences between object scbema 

structure denned by a pointer structure faS™ as a Program 45 ^ store schema, there is a need for a method of, and 

Communication Block or PCB), wherein each segment g^?^ 

consists of fields, and wherein certain fields may be keys ^ St ° rC Schema *** ob ^ schema " 

(indexes), and wherein certain segments may be links or 10 wew of me above > ^ere is a need for a method of * 

pointers to other segments (pointer segment). „ apparatus for, allowing a user to define a mapping between 

In the relational data model, the fundamental structure is conventi ™al data store schema and object schema, 

the relation, which is a two-dimensional matrix consisting of 1x1 wew of me sibavc > ***** b a need foT a method of, and 

columns and rows of data elements. A table is an instance of apparatus for, allowing a user to represent such, a definition 

a relation in the relational data base. Each table has a name. of . a ^PP^g between conventional data stare schema and 

A table must consist only of atomic fields of data, ie., each 55 ot >ject schema. 

field is a simple, indivisible type of data. A field is the basic ^ view of the above differences between conventional 

unit of data representing one data fact. data store schema, there is a need for a data store indepen- 

Each column has a label and contains atomic values of the dent method of, and apparatus for, meeting the above needs, 

same data type, wherein each atomic value is an attribute k view of the above, there is a need for an object oriented 

drawn from a set of possible values that is that column's 60 language independent method of, and apparatus f or, meeting 

domain. The order of columns is not significant and may be the above needs. 

changed without changing the meaning of a tuple. Each In view of the above, there is a need for a distributed 

column may be referred to by a unique pairing of the table client/server method of, and apparatus for, meeting the 

name with the column label. above needs. 

Each table consists of zero or more tuples , which are rows 65 In view of the above, there is a need for a method of, and 

of attribute values. Each row represents one relationship, apparatus for, providing a user an improved user interface to 

and a row's identity is determined by its unique content, not meet the above needs. 
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SUMMARY OF THE INVENTION the data store independent Schema Mapping Definition 

The invention disclosed herein comprises a method of, Language, the data store independent Schema Mapping 
and system for, mapping and accessing objects from a Internal Representation, and the single, uniform, data store 
conventional data store. The invention disclosed herein also independent interface to a Data Store Manager, 
comprises a method of, and system for, providing a high 3 m accordance with another aspect of the present 
level language for mapping and accessing objects from a invention, object oriented language independence is pro- 
conventional data store. The invention disclosed herein also vided by the use of the object oriented language independent 
comprises a method of, and system for, providing a user Schema Mapping Definition Language, the object oriented 
interface for mapping and accessing objects from a conven- language independent Schema Mapping Internal 
* tional data store. 10 Representation, and Code Generators which generate code 

Id accordance with one aspect of this invention, an object "} variou s object oriented languages from the Schema Map- 
oriented application prograinming interface to a data store P in S mtcrnal Representation for accessing objects from data 
manager provides a uniform and single interface for access- storcs - Tncse ( ^ ode Generators may be used to generate 
ing one or more conventional data stores, regardless of the access ^thods based on the Schema Mapping Internal 
type of conventional data store. 15 Representation for accessing objects from a data store. To 

In accordance with another aspect of the present P^ de such ac^ss to a dato store, a C(>de Generator may 

invention, a Smart Schema allows a user to mad between f nerate a combuiat io* °f object oriented prograniming 

object schema and conventional data store schema, regard- data store access language. The system then 

less of the type of conventional data store. „ n g cne * ates a make describing the dependency of files, 

In accordance with another aspect of the present "7 0 * es * e ^ 

invention, a user may define a mapping between object ^ies, and creates executable code for accessing a data 
schema and data store schema by use of a high level 

language, Schema Mapping Definition Language. The user m accord ance with another aspect of the present 

may either write SMDL directly or generate SMDL through 2 s invciI,io11 ' distributed client/server access of objects from 

the use of the Smart Schema, The Schema Mapping Defi- conventional data stores is provided by use of one or more 

nition Language is data store independent, object oriented aicnt Data Managers and one or more Server Data 

language independent and extensible. Storc Managers. 

In accordance with another aspect of the present ^ accordance with another aspect of the present 
invention, a definition of a mapping between object schema 30 invent ion, a graphical user interface, Smart Schema, is 
and conventional data store schema is represented by a provided for mapping object schema to data store schema 
Schema Mapping Internal Representation. The Schema wherein the graphical semantics support the Schema Map- 
Mapping Internal Representation contains representations of P* n £ Definition Language semantics. Another graphical user 
the object schema, the data store schema, and the mapping interface, Smart Access, allows an end user to access objects 
of the object schema and the data store schema. These 35 ^ a data store without the end user having to do any write 
representations are such that the Schema Mapping Internal application progrcurirning. The Smart Access user interface 
Representation may be accessible by both development allows the user to test mapping and access methods regis- 
interfaces (Smart Schema and Smart Access) and run-time ^d with the Data Store Manager without having to write 
environments, or it may by used to generate an object m application to access the objects from the data store in a 
oriented programming language for providing direct access 40 ^n"*" 116 environment. 

to a data store. It supports the accessing of the mapping tvrtrf nF<irRTPrrn*i n™ nT?AWrwr c 

information given either the object schema or data store BRIEF Dffi CMPrraN OF THE DRAWINGS 

schema. In other words, the data store schema may be For a more complete understanding of the present inven- 

accessed from the object schema, or the object schema may tion and the advantages thereof, reference is now made to 

be accessed from the data store schema. The Schema Map- 45 the Detailed Description in conjunction with the attached 

ping Internal Representation is generated by a Schema Drawings, in which: 

Mapping Definition Language Parser which parses the FIG. 1 shows the components of a system for mapping 

Schema Mapping Definition Language into the Schema an d accessing objects in a data store; 

Mapping Internal Representation. A Schema Mapping Defi- CTr * c ^ we . , , 

niriftnT! n «,, 4n «r^rLt^* 1 u a* + FIG. 2 snows the components of a system for mapping 

muon Language Generator may also be used to generate the 50 obiects in a data store- 

Schema Mapping Definition Language from the Schema * , . 7 * 

Mapping Internal Representation. The Schema Mapping J 10 ' f sh ° ws me com P onents of a system for accessing 

Internal Representation, the Schema Mapping Definition ob J ccts in a data store; 

Language Generator, the Schema Mapping Definition Lan- HG * 4 snows a preferred embodiment of this invention in 

guage Parser, and the Schema Mapping Definition Language 55 a client/server environment having various different types of 

reside in a Data Store Manager after a user has registered the s tores such as a relational database and a hierarchial 

mapping and access methods with the Data Store Manager. database; 

The Data Store Manager may utilize the Schema Mapping 5 shows the components for generating an object 

Internal Representation which embodies the mapping defi- oriented programming language and a data access language 

nition in order to access objects from a data store. The eo for providing direct access to data stores; 

Schema Mapping Internal Representation may be used by a FIG. 6 shows a system for mapping objects in a data store 

run-time environment to provide direct access to a data and generating a object oriented prograrmning language and 

store, or it may be used to generate an object oriented a data access language for providing direct access to a data 

rffogramming language for providing direct access to a data store; and 

store - m 65 FIG. 7 through FIG. 27 illustrate graphical user interfaces 

In accordance with another aspect of the present of a preferred embodiment of the Smart Schema portion of 

invention, data store independence is provided by the use of the present invention. 
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DESCRIPTION OF THE PREFERRED interface 110 to define the mapping or use the Schema 

EMBODIMENT Mapping Definition Language (SMDL) high level language 

1 Overview directly to define the mapping. As such, SMDL is created, 

' FIG. 1 shows the components of the preferred embodi- e ^f a user ' or * { X^ d ^ from 
raent of this invention for mapping and accessing objects in 5 the internal data structure SMIR. See Section 4 ("Schema 
a data store. The term data store is used herein to mean any Mapping Definition Language") below for a more detailed 
persistent storage including, but not limited to, relational description of a preferred embodiment of the Schema Map- 
databases, hierarchial databases, network databases, object P^g Definition Language. 

oriented databases, indexed file systems, or flat file systems. The system 100 also includes a Schema Mapping Defi- 

The preferred embodiment maps objects to a relational io virion Language parser 240 which parses the SMDL high 

database or hierarchial database and then accesses those level language into the SMIR 2110. Given the definition of 

objects from the respective databases. The system herein can the SMIR in Section 3 ^Schema Mapping Internal Repre- 

also be used to map objects to object oriented databases and sentation") below and the definition of the SMDL in Section 

to access those objects from the database, or to map and 4 ("Schema Mapping Definition Language'*) below, those 

access object from other persistent storage such as network is skilled in the art recognize that existing parsing and code 

databases or file systems. generation techniques may be used to implement the 

A graphical user interface, referred to as Smart Schema, Schema Mapping Definition Language (SMDL) generator 

110, FIG. 1, maps object schema to data store schema. The 220 and the Schema Mapping Definition Language parser 

Smart Schema has three Darts: Object Schema Generator, 240. 

Relational Schema Generator, and Schema Mapper. See 20 After a user has defined object schema, data store schema, 
Section 2 ("Smart Schema") below for a more detailed and the mapping between the object schema and data store 
description of a preferred embodiment of the Smart Schema. schema, and generated access methods using the Smart 
la mapping object schema to data store schema, the schema Schema 110, the user may register the mapping and access 
mapper of the Smart Schema can access the object schema methods with a Data Store Manager (DSM), 340, 350, 360, 
information from a repository 130 of object schema by the 25 370, or 380, to provide access of objects from a data store 
object schema access, 120. For example, the repository 130 (450, 460, 470, 480, or 490 of FIG. 4) in a run-rime 
may be the Object Management Group (OMG) Interface environment. A graphical user interface, Smart Access, 310, 
Repository or IBM's System Object Model (SOM) Interface is provided for such registration. In addition, the Smart 
28 Repository as described in SOM Toolkit Users Guide, Access user interface 310 allows the user to test mapping 
Version ZO, June 1993. The smart schema can also access 30 and access methods registered with the Data Store Manager 
the data store schema from a data store schema repository without having to write an application to access the objects 
150 by the data store schema access 140. For a relational from the data store in a run-time environmerit. Smart Access 
database, the data store schema repository 150 is the rela- 310 provides the capabilities to select a class and perform 
tional database catalog. See Section 3 ("Schema Mapping object manipulation operations such as adding, retrieving, 
Internal Representation") below for a more detailed descrip- 35 updating, deleting, and querying objects from the data store, 
tion of and an example of an object schema and a data store To accomplish this object manipulation through data store 
schema. access, the Smart Access graphical user interface 310 calls 
The above user interface, including the Smart Schema 110 an object-oriented application programing interface (API), 
and the object schema access 120 and the data store schema Object Call Level Interface, OCU, 320. Although a user 
access 140, allows a user to map object schema to a data 40 (end user, programmer, or an application program) may 
store schema. The system of this invention then embodies, access data objects through the OCU API 320 directly, 
in a data structure, Schema Mapping Internal Rcpresenta- independently of the Smart Access graphical user interface 
tion. (SMIR) 210, the mapping of the object schema to a data 310, the Smart Access graphical user interface 310 allows an 
store schema from the user interface. The internal data end user to access objects without the end user having to do 
structure 210, contains representations of the object schema, 45 any write application programming, 
the data store schema, and the mapping of the object schema The OCU API 320 is based on the Object Management 
and the data store schema. These representations are such Group (OMG) Persistent Object Service API as described in 
that the SMIR may be accessible by bom development IBM/JOSS Object Services Persistence Service Specifica- 
interfaces (Smart Schema 110 and Smart Access 310) and tion, OMG TC Document 93.5.7, Nov. 15, 1993, herein 
run times 330 and 340. The SMIR supports run-time and so incorporated by reference; or OMG Common Object scar- 
facilitates the accessing of the mapping information given vices Specification (COSS) Volume 1, herein incorporated 
either the object schema or data store schema. In other by reference. 

words, one may readily access the data stare schema from A run-time component may execute the OCU API 320 

the object schema, or one may readily access the object and implement the accessing of objects from a data store, 

schema from the data store schema. The SMIR 210 can be 55 Referring now to FIG. 4, the run-time component, generally 

used by aiun-time environment, or it can by used to generate referred to as 500, i.e., environment, comprises, for each 

an object oriented programming language for providing client, a client data store manager 330; and one or more 

direct access to a data store, as described below. The system server data store managers (DSM) 350, 360, 370, and 380. 

100 can also automatically layout or generate the graphical As further shown in FIG. 4, the client data store manager 

user interface representation of the mapping from the inter- 60 330 provides a uniform and single interface to server data 

nal data structure SMIR. See Section 3 ("Schema Mapping store managers, regardless of the type of data store in the 

Internal Representation") below for a more detailed descrip- server, generally referred to as 550. For example, data store 

tion of a preferred embodiment of the SMIR. manager 360 for a relational database (RDB) 470 may use 

The system 100 includes a Schema Mapping Definition embedded dynamic SQL statements to access data, or a data 

Language (SMDL) generator 220 which generates, from the 65 store manager 370 for the relational database 470 may use 

SMIR, a high level language (SMDL) 230 which represents X70pen SQL call level interface (CU) to access data. A 

the mapping. The user has a choice of either using the user client/server data store manager 350 can access both a DB2 
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database 450 and an IMS/DB database 460, and can provide 
caching and staging capability. For example, data can be 
downloaded to a mobile computer and uploaded at a later 
time. A data store manager 380 can access an IMS/DB 
database 490. The client data store manager 330 delegates 
and routes a call from the OCLI API to the proper server data 
store manager. 

As shown in FIG. 3, the SMIR internal data structure 210, 
the SMDL generator 220, the SMDL parser 240, and the 
SMDL high level language 230 reside in each server data 
store manager 340. The server data store manager 340 
utilizes the SMIR data structure 210 which embodies the 
mapping definition in order to access objects from a data 
store. The EMIR data structure 210 may be used by a 
run-time environment 500 to provide direct access to a data 
store. The EMIR data structure may also be used to generate 
an object oriented prog rammin g language for providing 
direct access to a data store. 

To provide such access to a data store, code "generators 
may be used to generate access methods based on the EMIR 
data structure. Referring now to FIG. 5, a code generator, 
such as 410, may generate System Object Module (SOM) 
interface definition language (SDL), C++ programming lan- 
guage, and embedded SQL codes from the SMIR 210. 
Another code generator, such as 420, may generate C++ 
programming language, and embedded SQL codes from the 
SMIR 210. Other code generators could generate other 
object oriented programming languages such as SmallTalk, 
and other data access languages such as DL/1. Each code 
generator generates a combination of a object oriented 
programming language such as C++, and a data access 
language such as SQL. Hie system then generates a make 
file describing the dependency of files, invokes the proper 
compilers, links the appropriate run-time libraries, and cre- 
ates executable code for accessing a data store. For a more 
detailed description of code generation, see Section 5. 
("Code Generation"). 
2. Smart Schema 

A graphical user interface, referred to as smart Schema, 
110, FIG. 1, maps objects schema to a data store schema. 
The Smart Schema has three parts: Object Schema 
Generator, Relational Schema Generator, and Schema Map- 
per. 

The Object Schema Generator allows a user to define 
object classes and generate the corresponding IDL (Interface 
Definition Language). The Relational Schema Generator 
allows the user to define relational tables and generate the 
corresponding tables in the selected databases. The Schema 
Mapper allows the user to define a mapping between the 
relational schema and the object schema. FIG. 7 shows the 
main screen 700 for Smart Schema. The user may select one 
of the Smart Schema components by clicking on the appro- 
priate icon, icon 710 to select the Relational Schema 
Generator, icon 720 to select the Object Schema Generator, 
or icon 730 to select the Schema Mapper. 
2.1. Object Schema Generator 

If the user selects the Object Schema Generator icon 720. 
then the Object Schema Generator Window 800 shown in 
FIG. 8 is displayed. The Object Schema Generator allows 
the user to define new classes. The user may define 
attributes, methods, types, and inheritance by clicking and 
keying in text information. When the user has completed 
such a definition, the user may request the Object Schema 
Generator to generate the IDL for the class or classes which 
the user has defined. 

Within the Object Schema Generator Window 800, a 
menu bar 810 is displayed containing selectable menu items, 
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File 820, Schema 830, Config. 840, and Help 850. The user 
may select one of the menu items to display a corresponding 
pulldown menu. The pulldown menus display and allow the 
user to select the following functions: 
5 File 820 

Close — exit Object Schema Generator and return to 

Smart Schema main screen 
quit — exit Smart Schema 
Schema 830 
10 Add class — add a new class 

Add subclass — add inheritance relationship between 
classes 

Select classes — select existing IDLs and display them 
on the screen 
15 Config 840 

Directory — specify the directory for the generated IDL 

file. The default is the current directory. 
Makefile— generate a makefile for all the classes on the 
2Q diagram. 

In addition, when the user clicks on a class, such as the 
class Animal 860, a popup menu appears with the following 
menu items: 

Class — use this item to change the name of the class or 

25 delete the class from the screen. 

Attributes — use this item to add or change attributes 
Types — use this item to add or change types 
Methods — use this item to add or change methods 
Generate— use this item to generate IDL for the class 

30 If the user desires to delete an inheritance relationship, 
such as the inheritance relationship 870 between class 
Animal 860 and its subclass Dog 880, the user may click on 
the relationship 870, and select a Delete menu item on a 
popup menu that appears. 

35 Object schema defined by use of the Smart Schema 
Object Schema Generator are specified based on the Object 
Definition Language (ODL) defined in the ODMG-93 Stan- 
dard (R. G. G. Cattell (Ed), The Object Database Standard: 
ODMG-93, Morgan Kaufmann Publishers, San Mateo, 

40 Calif., 1994). ODL is a superset of the Interface Definition 
Language (IDL) defined in CORBA (The Common Object 
Requester Broker Architecture and Specification, OMG TC 
Document 91.12,1, 1991.). As such, it is also a superset of 
the Data Definition Language (DDL) defined in the OMG 

45 Object Persistence Service Specification (IBM/JOSS Object 
Services Persistence Service Specification, OMG TC Docu- 
ment 93.5.7, Nov. 15, 1993). 

Table 1 lists and describes the data types defined in ODL. 
These are identical to the ones defined in IDL, which is a 

so subset of ODL. 

2.2. Relational Schema Generator 

Referring now back to FIG. 7, if the user selects me 
Relational Schema Generator icon 710, then the Relational 
Schema Generator Window 900 shown in FIG. 9 is dis- 

55 played. The Relational Schema Generator allows the user to 
define relational schema such as new relational tables and 
views. The user may define columns, keys, join conditions, 
and other relational items by clicking and keying in text 
information. When the user has completed such a relational 

60 definition, the user may create the table or view in the 
selected database. 

Within the Relational Schema Generator Window 900, a 
menu bar 910 is displayed containing selectable menu items, 
File 920, Schema 930, Config 940, and Help 950. The user 

65 may select one of the menu items to display a corresponding 
pulldown menu. The pulldown menus display and allow the 
user to select the following functions: 
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Hie 920 

close— exit Relational Schema Generator and return to 

Smart Schema main window 
quit— exit Smart Schema 
Schema 930 5 
Add Table — add a new tabic 

Select Tables — this shows a list of databases and tables 

on the selected system. 
Add View — add a new view 
Config 940 10 
Displays a list of the available relational database 
systems accessible by the user so that the user may 
select a particular relational database system, Le., 
IBM DB2/2 or IBM DB2/6000 for example. 
Depending upon the relational database system 15 
selected, or not selected, in which case a default is 
used, the Relational Schema Generator may display 
a list of databases and tables provided by the selected 
relational database system. 
In addition, when the user clicks on a table or a view, such 20 
as the Employee table 960, a popup menu appears with the 
following menu items; 
Table/View — use this item to change the name of the 

table/view or delete the table/view from the screen. 25 
Create — use this item to create the table/view in the 
database 

Drop — use this item to drop the table/view from the 
database 

Show SQL — show the SQL statement for creating/ 30 
dropping the table 

Relational schema defined by use of the Smart Schema 
Relational Schema Generator are specified based on the - 
IBM Structured Query Language (SQL) defined in the IBM 
SQL Reference Version 1, First Edition, August 1993. 35 

Table 2 lists and describes the data types defined in SQL, 
2.3. Schema Mariner 

This section specifies the external design of the Schema 
Mapper which provides object to data store schema map- 
ping. The design is intended to be general, particularly on 40 
the object side,. such that it applies to all types of data stores. 
For the purposes of describing the following preferred 
embodiment of the Schema Mapper, mappings between 
relational data stores or other types of data stores which 
support a relational API (e.g., X/Open CO or ODBC) and 45 
objects are presented; however, the design allows tailoring, 
particularly on the data store side, for each specific type of 
data store. 

For a relational to object mapping, i.e., to materialize 
tulles into objects, the Schema Mapper must be able to 50 
represent the tuples in an object schema. In the Schema 
Mapper: 

each table is represented as an interface type, 

each column is represented as an attribute, and 

each row is represented as an object. 

For an object to relational mapping, i.e., to store objects 
in a relational data store, the Schema Mapper must be able 
to represent the objects in a relational schema. In the Schema 
Mapper: 

each interface type is represented as a table, 

each attribute is represented as a column, and 

each object is represented as a row. 

Referring now back to FIG. 7, if the user selects the 
Schema Mapper icon 730, then the Schema Mapper Window 65 
1000 shown in FIG. 10 is displayed. The Schema Mapper 
allows the user to define a mapping between a relational 
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schema and an object schema. The Schema Mapper supports 
the following mapper configurations: 
Table to Class 

1 table to 1 class 

1 table to many classes 

many tables to 1 class 
Class to Table 

1 class to 1 table 

1 class to many tables 

many classes to 1 table 
Column to Attribute 

1 column to 1 attribute 

1 column to many attributes 

many columns to 1 attribute 
Attribute to Column 

1 attribute to 1 column 

1 attribute to many columns 

many attributes to 1 column 
In addition, Schema Mapper supports the following four 
scenarios depending upon if the table exists or not, and 
depending upon if the class exists or not: 

1. Classes and Tables both exist; in which case, the user 
may define the mapping between them. 

2. Classes exist but not Tables; in which case, the user 
may select the existing classes, define the mapping 
from the existing classes to the tables, and then create 
the corresponding tables. 

3. Tables exist but not Classes-; in which case, the user 
may select the tables, define the mapping from the 
existing tables to the classes, and then generate the 
corresponding IDLs. 

4. Both Classes and Tables do not exist; in which case* the 
user may use the Object Schema Generator or the 
Relational Schema Generator to define either or both 
schema. After that, the user may follow one of the 
above three steps to define mappings. 

When the user has completed defining the mapping between 
tables and classes, the user may capture the mapping con- 
figuration by generating a Schema Mapping Definition Lan- 
guage (SMDL) description of the mapping. 

Referring again to FIG. 10, within the Schema Mapper 
Window 1000, a menu bar 1010 is displayed containing 
selectable menu items, File 1020, Schema 1030, Map 1040, 
and Help 1050. The user may select one of the menu items 
to display a corresponding pulldown menu. The pulldown 
menus display and allow the user to select the following 
functions: 

File 1020 

New — clear the current screen and start over again. 

Open — open existing SMDL files and display the map- 
ping infarmation on the screen. This allows the user 
to modify mapping information. 

Close — exit Schema Mapper and return to Smart 
Schema main window. 

Quit — exit Smart Schema 
Schema 1030 

Select classes — select existing classes from either the 
Interface Repository or to the IDL file. 

Select tables — select existing tables from selected rela- 
tional database system. 
Map 1040 

Link — indicates mapping relationship between 
schema. 

Generate SMDL — generates SMDL corresponding to 
the mapping between the schema. 
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The operation of the Schema Mapper supporting the 
above four scenarios, depending upon if the table exists or 
not, and depending upon if the class exists or not, will now 
be discussed. 

23.1. Schema Mapper Scenario 1: Gasses and Tables Both 5 
Exist 

For the scenario where the classes and tables both exist, 
six additional scenarios are presented: three scenarios in 
which existing table(s) are mapped to existing class(es), and 
three scenarios in which existing class(es) are mapped to 10 
existing table(s). For the mapping of existing table(s) to 
existing class(es), the three scenarios presented are mapping 
one existing table to one existing class, mapping one exist- 
ing table to two existing classes, and mapping many existing 
tables to one existing class. For the mapping of existing 15 
class(es) to existing table(s), the three scenarios presented 
are mapping one existing class to one existing table, map- 
ping one existing class to two existing tables, and mapping 
many existing classes to one existing table. 
2.3.1.1 Mapping One Existing Table to One Existing Class 20 

In this scenario, the user selects an existing table 
Employee and an existing class Person. Referring back to 
FIG. 10, the user selects the existing table Employee by 
clicking on the Schema menu item 1030 from the menu bar 
1010. Referring now to FIG. 11, from a subsequently 25 
displayed Schema pulldown menu 1110, the user clicks on 
the Select Tables item 1120 which displays a listbox 1130 
listing existing tables from which the user may select Hie 
user may then click on Employee 1140 within the listbox to 
select the Employee table. This causes the Employee table 30 
icon 1060 to be displayed within the Schema Mapper 
Window 1000 as illustrated in FIG. 12. 

To select the existing class Person, the user follows a 
similar process. Referring now to FIG. 13, the user clicks on 
the Schema menu item 1030 from the menu bar 1010. From 35 
a subsequently displayed Schema pulldown menu 1110, the 
user clicks on the Select Classes item 1310 which displays 
a listbox 1320 listing existing classes from which the user 
may select The user may then click on Person 1330 within 
the listbox to select the Person class. This causes the Person 40 
class icon 1070 to be displayed within the Schema Mapper 
Window 1000 as illustrated in FIG. 14, 

Referring now to FIG. 15, to define a mapping between 
the existing Employee table and the existing Person class, 
the user clicks on the Map menu item 1040 from the menu 45 
bar 1010. From a subsequently displayed Map pulldown 
menu 1510, the user clicks on the Link item 1520, and then 
the user clicks on the Employee table icon 1060 and the 
Person class icon 1070 to indicate that the Employee table 
and Person class are linked, i.e., that the Employee table 50 
schema will be mapped to the Person class schema. To 
indicate this link, a link arrow icon 1080 is drawn between 
the Employee table icon 1060 and the Person class icon 1070 
as illustrated in FIG. 16. 

The user may then click on the arrow icon 1080 to 55 
indicate that the user wishes to define the mappings between 
the Employee table columns and the Person class attributes. 
After the user clicks on the arrow icon 1080, a Define 
Mapping Info Window 1700 is displayed as illustrated in 
FIG. 17. The Employee table column names 1705, 1710, 60 
1715, and 1720 are displayed on the left hand side of the 
Define Mapping Info Window 1700. A Combo box 1725 that 
contains all the attributes of the Person class is shown on the 
right hand side of Define Mapping Info Window 1700. The 
user may then specify which Employee table columns map 65 
to which Person class attributes. To specify a mapping, the 
user clicks on the Add icon 1730; clicks on the Employee 
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table column name to be mapped, for example, empNum(k) 
1705; clicks on the Combo box list button 1735 to display 
a listbox 1740 containing a list of the Person class attributes 
(serialNumber 1745, name 1750, day 1755, month 1760, and 
year 1765); and then clicks on the Person class attribute 
name to be mapped, for example, serialNumber 1745. This 
results in the selected Employee table column name being 
mapped to the selected Person class attribute, for example, 
empNum(k) being mapped to serialNumber. The user may 
repeat this process to define other column to attribute 
mappings. 

For the cases where a column maps to more than one . 
attribute or where many columns map to one attribute, a user 
exit function may be defined. A user exit function allows the 
user to specify user defined mapping functions. 

Referring now to FIG. 18, a subsequent Define Mapping 
Info Window 1800 resulting from such a process of user 
specified mappings is shown. The Define Mapping Info 
Window 1800 displays the table column to class attribute 
mappings. The table column empNum(k) 1705 is mapped to 
the class attribute serialNumber 1805. The table columns 
firstName 1710 and LastName 1715 are mapped to the class 
attribute name 1810 and 1815. In this example, the user, or 
did not define an exit function, and the default implemen- 
tation concatenates the two columns firstName 710 and 
LastName 1715. The table column hireDate 1720 is mapped 
to three class attributes: day 1820, month 1825, and year 
1830, and an user exit function is provided which the user 
defined by selecting the userFctl button 1875, 

To represent tuples in an object schema, each data type in 
the relational schema must map to an equivalent data type in 
the object schema. In addition to mapping table columns to 
class attributes, the: Schema Mapper also maps the table 
data types to attribute data types. By default a default SQL 
data type to ODL data type mapping is provided. This 
default mapping is specified in Table 5. In an alternative 
embodiment, the user may also override the default datatype 
conversion for any particular table column datatype to class 
attribute datatype. In such an alternative embodiment the 
default datatypes may be displayed in addition to the table 
column to class attribute mapping. The user may click on the 
default datatype to display a listbox of allowable datatypes 
from which the user may select by clicking to override the 
default datatype. The allowable override mappings from 
which the user may select are specified in Table 4. In still 
another alternative embodiment, the user may click on the 
table column or class attribute to display a details listbox 
containing the default datatype. The user may then click on 
the default datatype to display a listbox of allowable 
datatypes from which the user may select by clicking to 
override the default datatype. 

2.3.1.2 Mapping One Existing Table to Two Existing Classes 
Referring now to FIG. 19, in this scenario, the user wants 
to map one existing table Employee 1910 to two existing 
classes: SalaryEmp 1920 and RegularEmp 1930. Similar to 
the above scenario, the user selects the table and the classes, 
and then defines the links between them. 

The user then clicks on the link arrow 1940 between table 
Employee 1910 and class SalaryEmp 1920. A screen similar 
to FIG. 17 is displayed for mapping the Employee table 
columns to the class SalaryEmp attributes. The user then 
defines the column to attribute mapping from the Employee 
table to the SalaryEmp class in the same manner as 
described above. 

The user then repeats the above process for the Employee 
to RegularEmp KnV arrow 1950. 
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2.3.1.3 Mapping Many Existing Tables to One Existing 
Class 

Referring now to FIG. 20, in this scenario, the user wants 
to map many existing tables to one existing class. For 
example, the user may map table Employee 2010 and table 5 
Address 2020 to the class Person 2030. The user is provided 
with two alternative processes for specifying such a map- 
ping. 

Under the first alternative, the user may define a view on 
the many tables. The user may then specify the join condi- 
tions between the tables and the output columns in the view. 10 
Then, the user may map the view table to the class. In effect, 
this is similar to the above Mapping One Existing Table to 
One Existing Class Scenario where one table (one view 
table) is mapped to one class. The user may first use the 
Relational Schema Generator to define the view on the many 3 
tables. The user may then follow the above Mapping One 
Existing Table to One Existing Class Scenario to define the 
mapping between the view table columns and the class 
attributes. 

Under the second alternative, the user may select multiple 
tables, define join and conditions between the tables, and 20 
then map to a class. An advantage of this second alternative 
is that it does not require a view table to be defined. 
Referring again to FIG. 20, the user links the table Employee 
2010 and the class Person 2030 yielding link arrow 2040. 
Next the user links the table Address 2020 and the class 
Person 2030 yielding link arrow 2050. In this particular 25 
case, clicking on each link arrow, 2040 or 2050, and defining 
the columns to attributes mapping is not sufficient because 
joins or conditions may need to be specified. Therefore, in 
this case, the user is required to first draw all the m-1 links 
(link arrows 2040 and 2050), then click on the target (the 30 
class Person 2030), and then specify mapping. This process 
allows the Schema Mapper to recognize that a join or 
condition clause may be necessary and to prompt the user for 
such join or condition clause. 

2.3.1.4 Mapping One Existing Class to One Existing Table 35 
Referring now to FIG. 21, in this scenario, the user wants 

to map an existing class Person 2110 to an existing table 
Employee 2120. When the user clicks oh the link arrow 2130 
between the class Person 2110 and the table Employee 2120, 
the Define Mapping Info Window of FIG. 22 is displayed. 

On the left hand side of the Define Mapping Info Window 40 
2200, the Person class attribute names (seriatNtamber 2205, 
name 2210, day 2215, month 2220, and year 2225) are 
displayed. A Combo box 2230 that contains all the columns 
of the table Emmployee is shown on the right hand side of 
the Define Mapping Info Window 2200. The user may click 45 
on the Combo box list button 2235 to display a Hstbox 2240 
containing a list of the Employee table columns (empNum 
2245, firstName 2250, lastName 2255, and hireDate 2260). 
Similar to the table to class mapping described above, the 
user may then select which attribute to map to which 50 
column. For the cases where an attribute maps to more than 
one column or where many attributes map to one column, a 
user exit function may be defined. 

Referring now to FIG. 23, the results of such a class 
attributes to table columns mapping is illustrated. The 55 
attribute serialNumber 2305 is mapped to the columns 
empNum 2345. The attribute name 2310 is mapped to the 
columns firstName 2350 and LastName 2355. An exit func- 
tion may be defined by selecting the userFctl button 2375 to 
specify how the attribute name 2310 is split into the two 
columns firstName 2350 and LastName 2355. The three 60 
attributes: day 2315, month 2320, and year 2325 are mapped 
to the one column hireDate 2360, 2365, and 2370. Since an 
exit function is not provided by the user in this case, the 
default implementation concatenates the three attributes 
values. 65 

As part of representing objects in a relational schema, one 
must map each data type in the object schema to an 
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equivalent data type in the relational schema. In addition to 
mapping class attributes to table columns, the Schema 
Mapper also maps the attribute data types to table column 
data types. By default, a default ODL data type to SQL data 
type mapping is provided. This default mapping is specified 
in Table 6. The allowable override datatype mappings from 
which the user may select are specified in Table 3. 

2.3.1.5 Mapping One Existing Class to Two Existing Tables 
Referring now to FIG. 24, in this scenario, the user wants 

to map one existing class Person 2410 to two existing tables: 
SalaryEmp 2420 and RegularEmp 2430. The user may dick 
on the link arrow 2440 between the class Person 2410 and 
table RegularEmp 2420 to display a window for mapping 
attributes to columns similar to the Define Mapping Info 
Window 2200 of FIG. 22. The user may then define the 
attribute to column mapping from the class Person 2410 to 
the table RegularEmp 2420. The user may then repeat the 
above process for the Person to SalaryEmp link arrow 2450. 

2.3.1.6 Mapping Many Existing Classes to One Existing 
Table 

Referring now to FIG. 25, in this scenario, the user wants 
to map many existing classes to one existing table. This 
situation may arise in an inheritance hierarchy where the 
user wants to map all the attributes that are inherited into one 
table. Alternatively, the user may want to map multiple 
classes to one existing table even though the classes do not 
have any relationship to each other. The user may perform 
the process of the above described Mapping One Existing 
Class to One Existing Table on the class Person 2510 and 
table Employee 2520. The user may then repeat this process 
on the class Manager 2530 and table Employee 2520. 
Although this scenario also falls into the more difficult m-1 
scenarios, this scenario is simpler than the many tables to 
one class scenario as there is no need to specify joins or 
conditions. 

2.3.2 Schema Mapper Scenario 2: Classes Exist, But Not 
Tables 

For the scenario where the class(es) exist, but not 'the 
table(s), three additional scenarios are presented: mapping 
one existing class to one new table, mapping one existing 
class to many new tables, and mapping many existing 
classes to one new table. 

23.2.1 Mapping One Existing Class to One New Table 
Referring now to FIG. 26, in this scenario, the user selects 

an existing class Person 2610 and defines the corresponding 
table for the class. The user clicks on the class Person icon 
2610, and a popup menu 2620 appears where the user may 
click on an "Add Table" menu item 2630 to add a new table. 
As a result of clicking the "Add Table" menu item 2630, the 
user is prompted for a name for the new table via a prompt 
dialog. After the user enters the new table name into the 
prompt dialog, a table icon, the Employee table icon 2640, 
is added to the Schema Mapper Window 2600 with a link 
arrow 2650 between the class Person icon 2610 and the table 
Employee icon 2640. 

The new table contains the default column mappings for 
the attributes in the class. If the user wishes to override the 
default datatype mappings, the user may override them as 
described above. When the user is satisfied with the 
mapping, the user may request that the new table be created 
in the specified database repository. In an alternative 
embodiment, when a new table for a class is created, an extra 
column is created in the new table to store a FID (Persistent 
Identifier uniquely identifying a row in the table). This extra 
column is of type CHAR, and is used by the run-time to 
handle various situations, including use as a primary key to 
uniquely identify an objects OID (Object Identifier) to the 
PID of a row in a table. 

23.2.2 Mapping One Existing Class to Many New Tables 
Referring again to FIG. 26, in this scenario, the user 

selects an existing class Person 2610 and defines multiple 
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tables for the class. This is similar to the last scenario. The 2,5.1 Schema Icons 

user dicks on the class Person icon 2610 to display the The Schema Mapper uses different icons to represent 

popup menu 2620 from which the user selects the "Add different schema. The following are the three icon catego- 

Table" menu item 2630, and then follows the last scenario as ries: 

described above. The user then repeats this process as , class icon representing a class, 

needed for each new table. The user defines the columns in table icon representing a table, and 

each new table, and when satisfied, creates each new table relationship table icon representing a relationship table. 

in the database repository Note that the user has to be The relationship table icon has a different appearance from 

sensitive to the order of table creation if there are depen- that of the table icon, andis used to visually indicate that two 

denaes between the new tables. or more tables are being related by the represented relation- 

2.3 23 Mapping Many Existing Classes to One New Table 10 sh ip table. This is indicated by displaying a visual indicator 
In this scenario, the user selects many existing classes and from the relationship table icon, containing the primary 

defines mappings to one new table. This is similar to the keys, to each of the tables containing the foreign keys to 

many existing classes to one existing table scenario, except which the primary keys relate 

that the new table needs to be .created. Each category is further divided into two cases: 

233. Schema Mapper Scenario 3: Tables Exist, But Not ^ schema exist, and 

Classes schema does not exist 

For the scenario where the table(s) exist but not the Different semantic information is displayed for different 

class(es), three additional scenarios are presented: mapping icons. For example, for a non-existent table icon, there will 

one existing table to one new class, mapping one existing be a Create option to allow the user to create a new table, 

table to many new classes, and mapping many existing 2.5.2 Join 

tables to one new class. 20 a "Join" is meaningful when: 

2.3.3.1 Mapping One Existing Table to One New Class multiple tables are mapped to one class, or 

Referring now to FIG. 27, in this scenario, the user selects one class is mapped to multiple tables, 

an existing table Employee 2710 and defines the correspond- When either of these condition arise, the context menu for 

ing class. The user clicks on the table Employee icon 2710, th e class icon will show the "join** menu item The user may 

and a popup menu 2720 appears wherein the user may click 25 sc l cct this item to define the joins between the tables. Then 

on an "Add Class** menu item 2730 to add a new class. a Join Window allows the user to choose which table 

When the user clicks on the "Add Class** menu item 2730, columns on which to join. After the join is defined, a Define 

the user is prompted to enter a name for the new class via a MapP^g Mo Window similar to 2200 of FIG. 22 is dis- 

prompt dialog. When the user enters the new class name, a P^X™ fc jLS a2 ^P m % attributes to the columns resulting from 

class icon, the class Person icon 2740, is added to the * n ™ jom. The user rrmy men define me dass attribute to join 

Schema Mapper Window 2700 with a link arrow 2750 colu^ mappmg. 

between the table Employee icon 2710 and the new class A .^^n * . _^ , «_ 

Person icon 2740. A Union is meaningful when: 

The new class Person contains the default attribute map- multi P le ^es are mapped to one class, or 

pings for the columns in the table Employee. If the user one ™? 15 ^P^ to multiple tables, 

wishes to override the default mappings, the user may do so 35 Whcn tttIier of mcse c 011 ^ 011 arise, the context menu for 

as described above. When the user is satisfied with the * c class icon wiU show &e "Union 1 * menu item. The user 

mapping, the user may request that the JDL for the class be ^ Select ^ itcm t0 dcfinc * e unions between the tables, 

generated and stored in the selected object repository. ^ Union window aUows the user to choose which tables 

2.33.2. Mapping One Existing Table to Many New Classes fzom whicn **** class ^ data - 

Referring again to FIG. 27, in this scenario, the user 40 2 - 5 ; 4 ( £ on ^ on „ . . ^ , t 

selects an existing table Employee 2710 and defines multiple A Cot ^ ltioa 1S meaningful when: 

new classes for the table. This is similar to the last scenario. one class 1S ^P** 1 10 onc M ^ 

The user clicks on the class Person icon 2710 to display the onc class 1S n^PP^ t0 multiple tables, 

popup menu 2720 from which the user selects the "Add classcs mapped to one table, 

Class" menu item 2730, and then follows the last scenario as 45 one table is mapped to one class, 

described above. The user then repeats this process as one * s mapped to multiple classes, or 

needed for each new class. The user may define the attributes multiple tables are mapped to one class, 

in each new class, and when satisfied, generate IDL for each When one of these conditions arise, the context menu for the 

new class. class icon will show the "Condition" menu item. Hie-user 

2.3.33 Mapping Many Existing Tables to One New Class 50 may select this item to define the conditions for filtering data 

In this scenario, the user selects many existing tables and from the relational tables, 

defines mappings to one new class. TTiis is similar to the 2.5.5 OrderBy 

mapping many existing tables to one existing class scenario An "OrderBy" is meaningful when: 

except that the new class first needs to be generated one class is mapped to one table, 

2.4 Modifying Existing Schema Mappings one class is mapped to multiple tables, 
The Schema Mapper allows a user to change existing 55 many classes are mapped to one table, 

schema mappings. Hie Schema Mapper displays existing one table is mapped to one class, 

SMDL files on the screen, and allows the user to modify the one table is mapped to multiple classes, or 

SMDL, and then regenerate the SMDL files. The SMIR multiple tables are mapped to one class. 

provides APIs to retrieve the internal format. These APIs When one of these conditions arise, the context menu for the 

may also be used to retrieve information from existing 60 class icon will show the "Order By" menu item. The user 

SMDL files. may select this item to define the order by clause. An Order 

2.5 Schema Mapper graphical Mapping Semantics By Window allows the user to choose which table columns 
In this section, the various mapping semantics supported to order the results by and in what order (ascending versus 

graphically in Schema Mapper are discussed The mapping descending), 

semantics correspond to those that are supported in SMDL 65 2.5.6 Super Join 

In other wards, any semantics that are defined by the SMDL A super join refers to the situation where a join is defined 

may be specified graphically using the Schema Mapper. between tables mapped to the selected class and tables 
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mapped to a parent class (superclass) of the selected class 
(subclass). A super join menu item appears on popup menu 
displayed when the user clicks on the class icon. Selecting 
this super join menu item displays a super join dialog 
allowing the user to choose which tables, of those tables 
mapped to a parent class of the class, on which to perform 
a join with tables mapped to the class. Once the user has 
selected the , superclass tables and subclass tables upon 
which to perform a join, a Join Window allows the user to 
choose which table columns on which to join. Thereafter, the 
user proceeds the same as for a join. 

2.5.7 Direct References 

A direct reference refers to the situation wherein a class 
contains an attribute that references another class, and the 
user wishes to map this reference using a foreign key and 
primary key relation in the relational data store. The foreign 
key and primary key relation can be either direct from one 
table to another (Direct Reference) or indirect through a 
third table known as a relationship table (Indirect 
Reference). When an attribute is a reference, then a Refer- 
ence icon is displayed to indicate to the user that the user has 
to map either "Direct" or "Indirect If the user chooses 
direct", a Direct Reference dialog is displayed. The Direct 
Reference dialog fallows the user to verify that the mapping 
uses a column that is a foreign key from the From table, and 
that relates to a primary key in the To table. 

2.5.8 Indirect References (via Relationship Table) 

When the user selects "Indirect" from the above discussed 
Reference icon to map the reference attribute using an 
Indirect Reference, then the user is presented with a First 
Indirect Reference dialog allowing the user to choose which 
relationship table to use. After selecting the relationship 
table, a Second Indirect Reference dialog is displayed allow- 
ing the user to choose the To column from the relationship 
table. 

3. Schema Mapping Internal Representation (SMIR) 

The following example illustrates a sample schema map- 
ping definition. There are two classes in the Object Store: 
employee and department Corresponding to these two 
classes, there are three tables in the relational database 
repository: employee, address, and department The schema 
definition of the classes, the schema definition of the tables, 
the schema mapping definition between the tables and 
classes (expressed in SMDL), and a Schema Mapping 
Internal Representation data structure are presented. 

The definition of the two classes (the object schema), 
employee and department, are as follows: 



\begin{verbatim} 

class rich_employee 
{ 

public: 

char empno[JOOJ; 
int salary; 
char nameflOO]; 
char address[200]; 
department * dept; 
} 

class department 
{ 

public: 

char deptno[100]; 
char depmame[100j; 
os_Sct <rich_cmployce *> employee; 
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\begin{ verbatim) 

table employee 

column cno - string 
column ngrpft — string 
column salary — real 
column dependent — integer 
column workdept — sting 

table address 

column eno — string 
column address — string 

table department 

column duo — string 
column dpam c — string 
column manager — string 
\end{ verbatim} 



The schema mapping between the above classes and 
tables expressed in SMDL is as follows: 
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\cod{ verbatim} 



The definition of the three tables (the data store schema) 65 
in the relational database corresponding to the above two 
classes are as follows: 



\begm{verbatim) 

# This is schema mapping definition for employee-department 

# classes 

SCHEMA_MAPPJNG employee-department 

# class 

CLASS rich_employee 

JOIN "employee.eno = address .eno" 

CONDITION "salary > 400100 order by lastname desc" 

ATTRIBUTE empno 

ATTRTflUTE_TYPB string 

TABLE employee 

COLUMN eno 

TYPE string 
END_ATTRIBUTE 
ATTRIBUTE salary 

ATTRIBTJTE_TYPE real 

TABLE employee 

COLUMN salary 

TYPE real 
END__ATTRIBUTE 
ATTRIBUTE name 

ATTRTBUTE_TYPE string 

TABLE employee 

COLUMN name 

TYPE string 
END_JOTRmUTE 
ATTRIBUTE address 

ATTRD3UTE__TYPE string 

TABLE address 

COLUMN address 

TYPE string 
END_ATTRIBUTE 
END_CLASS 

# class 

CLASS department 

ATTRIBUTE depmo 

ATTRIBUTE—TYPE string 

TABLE department 

COLUMN depmo 

TYPE string 
END—ATTRIBUTE 
ATTRIBUTE deptnamc 

ATTRIBUTE— TYPE string 

TABLE department 

COLUMN depmame 

TYPE string 
END _ATTRIBUTE 
END_CLASS 

# relationship 
RELATIONSHIP dept 

FROM 1 

FROM—CLASS rich_employee 

FROM__ATTRfflUTE dept 

FROM— ATTRIBUTE_TYPE department* 

FROM— TABLE employee 

FROM—COLUMN workdept 

FROM-C OLUMN_TYPE string 
TO n 
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TO_CLASS department 
TO_jVITRIBirra employee 
T0_ATTRIB17EE_TYPE dept * 
TO_TABLE department 
TO_COLUMN dno 
TO_COLUMN__TYPE string 
END_RELAHONSHIP 

END_SCHEMA_MAPPING 

\end{ verbatim} 



The following is an example of a data structure repre- 
senting a Schema Mapping Internal Representation (SMIR) 
in which the above object schema, data store schema, and 
the mappiag of the object schema and the data store schema 
may be stored: 

Schema Mapping Internal Representation (C++ classes) 

DbSchemaMapping 

DbStore 

DbTable 

DbColumn 

DbClass 

DbAttr 

DbReference 

DbSchemaMapping class 

char* DbS chemaMappiug__g ctName() ; 

DbStore*DbSchcmaMapping_gctDatastore(); 

DbStore*DbSchcmaMapping_getNextDatastore(); 

Dbaass*DbSchemaMapping_getaass(); 

Dbaass*DbSchemaMapping^etNextClass(); 

DbReference*DbScbemaMapping_getReference(); 

DbRefei^cc*DbSchemaMappmg_getNextReference(); 

DbTable*DbSchcniaMapping_getTable(); 

DbTable*DbSchemaMapping_getNextTableO; 

void DbScheniaMapping__setName(char*mappingnamc); 

void DbSchemaMapping_setDatastore(DbStore*store); 

void DbSchemaMapping_setNextData store 

(DbStore*store); 
void DbSchemaMapping__setaass(DbClass*newclass) ; 
void DbSchemaMapping_setNextClass 

(Dbaass*newclass); 
void DbSchemaMapping_setReference(DbRefcrence*rcl); 
void DbSchemaMapping_setNextReference 

(DbReference*rel); 
void DbSchemaMapping_setTable(DbTable*newtable); 
void DbSchemaMapping_setNextTable 

(DbTable*newtable); 
DbStore *DbSchemaMapping_findData store 

(char*storename) 
DbClass *DbSchemaMapping_Jindaass (char*classname); 
DbTable*DbSchemaMappmg_JindTable (char*tablename); 
DbReference*DbSchemaMapping_flndReference 

(char*refname); 
char*DbStore_getNameO; 
char*DbStc[rc^etDbmsTypeO; 
char*DbStore_getDbName(); 
char*DbStore_getUserIdO; 
char*DbStore_getPasswordO; 
void DbStore„setName(char*storename); 
void DbStore_setDbmsl^pe (char*dbmsname); 
void DbStore_jsetDbName (char*dbname); 
void DbStare_setUserId (char*username); 
void DbStore _setPassword (char*passwd); 
DbTable Class 
char*DbTable_getName(); 
DbClass*DbTable_getClassO; 
Dbaass*DbTable_getNextClassO ; 
DrjColunan*DbTable^etColumn(); 
DbColurmi*DbTable^etNextColumnO; 
void DbTable__setName(char*tabname); 
void DbTablc_setaass(DbClass*cp); 



void DbTable_setNextClass(Dbaass*cp); 

void DbTable^etColurnnODbColurnn*colp); 

void DbTable_setNexColumn(DbColumn*colp); 

DbColumn class 
5 char*DbColumn_getNameO; 

int DbColumn_getiypcO; 

DbTable*DbCoiumn_getTable(); 

DbAtb*DbColumn_getArtr(); 

DbAttr*DbColumn_getNextAttr 0; 

void DbColumn^etName (char*colname); 
10 void DbColumn_sefiype(int coltype); 

void DbColium_setTable(DbTable*tp); 

void DbColumn jetAttr(DbAttr*ap); 

void DbColumn_setNextAttt(DbAttr*ap); 

DbClass class 

char*DbGass_getName(); 

DbClass*DbClass_getSuperclassO; 

char*DbQass_getSuperjoinO; 

char*DbQass_getJoinO; 

char* DbQas s_getCondition(); 

char*Dbaass_getOrderBy(); 
20 DbStore*DbOass_getStare(); 

DbTable*DbClass_getTable(); 

DbTable*Dbaass_getNextTable(); 

DbAttr*Dbaass_gctAttrO; 

DbAttr*DbClass_getNextAttrO; 
25 DbAttr*Dbaass_getNextSpUtAttr(); 

DbColumn*Dbaass_getKeyO; 

DbColumn*Dbaass_getNextKeyO; 

void DbOass_setName(char*classname); 
30 void Dbaass__setSupcrclasspbClass*supcrclass); 

void Dbaass^ctSuperjoin(char*jointcxt); 

void Dbaass_setJoin(char*jointext); 

void Dbaass_setCondition(char*condiriontext); 

void Dbaass_setQrderBy(char*orderbytext); 

void Dbaass_setStore(DbStore*dbstorep); 

void DbOass_settable(DbTable*tabp); 

void Db(^ss_setNextTable(DbTable*tat|p); 

void DbOass^etAttr(DbAttr*attr); 

void Dbaass_setNextAttr(DbAttr*attr); 

void DbCkss_setNextSpHtAttr(DbAttr*attr); 
40 void DbClass _setKey(DbColumn*keyp); 

void DbClass_jetNextKey(DbColumn*keyp); 

DbAttr class 

char*DbAttr_getNameO; 
int DbAttr_getType(); 
45 char*DbAttr_getFunction(); 
Dbaass*DbAttr_getClassO; 
DbColumn*DbAttr_getColumnO; 
DbColumn*DbAttr_^etNextColumnO; 
DbReference*DbAttr_getReferenceO; 

50 

void DbAttr_setName(char*attniame); 
void DbAttr_seOype(int attrtype); 
void DbAttr_setFunction(char*func); 
void DbAttr_setaass(Dbaass*cp); 
void DbAttr_setColumn(DbColumn*colp); 
void DbAtu*^etNextColurnn(DbColumn*colp); 
void DbAttr__setReference(DbReference*referp); 
DbReference class 
char*DbReference_getName(); 
// from class 
60 Dbaass*DbReference_getfrom(); 
DbAttr*DbReference_getFrattrO; 
DbTable*DbRef erence_getE^tableO ; 
DbTable»DbReference_getNextFrtable(); 
DbCk>lumn*DbReference_^etRrcolumnO; 
65 DbC^lumn*DbReference_getNextFrcolumnO; 
DbTable*DbReference_getFrreltable(); 
DbColumn*DbRef erence^etErrelcolumnO ; 
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DbColumn*DbReference_getNextFirelcoiumnO; 
// to class 

Db€lass*DbReference__getToO; 
DbTable*DbReference_getTotabIe(); 
DbTable*DbRcfcxcnce_gctNcxtTotableO; 
DbColumn*DbRcf crcncc_^ctTocolumnO ; 
DbColumn*DbReferenc€_getNextTocolumnO; 
DbTable*DbRefexence_getToreltable() ; 
DbColumu*DbRcfcrence_getTorclcolumiiO; 
DbColumn*DbRefexenoc_getNextTorelcolumn(); 
void DbReference_setName (char*relname); 
// from class 

void DbReference_setftom(DbClass fromclass); 
void DbReference_setfirattr (DbAttr attrp); 
void DbReference_setIrtable(DbTable*frtabp); 
void DbReference_setNextFrtable(DbTable*frtabp); 
void DbRefercnce_setRrcolumn(DbColuinn*frcolp); 
void DbRcfcrencc_setNextFrcolmnn(DbColumn , * , £rcolp); 
void DbRefcrcncc_sctRccltable(DbTable*fiTeltabp); 
void DbReference__ setr^lcolumn(DbColumn*rrrelcoIp); 
void DbRefer en ce_setNextFrrel column 

(DbColumn*firelcolp) ; 
// to class 

void DbReferenre_setTo(DbClass*toclass); 
void DbReference„setTotable(DbTable*totabp); 
void DbReference_setNex1Totable(DbTable*totabp); 
void DbRcf crcncc_sctTocolumn(DbColumn*tocolp) ; 
void DbReference_sctNex1Tocoliimn(DbColumn*tocolp); 
void DbReference_setToreltable(DbTable*toreltabp); 
void DbReference_setTorelcolumn(DbColumn*torelcolp); 
void DbRef erence_setNextTorel column 

(DbColumD*torelcolp); 
4. Schema Mapping Definition Language (SMDL) 

4.1. Introduction 

The system 100 includes a schema mapping definition 
language (SMDL) generator 220 which generates, from the 
internal data structure, a high level language (SMDL) 230 
which represents the mapping. 

This section describes the functional specification and 
relevant information of the Schema Mapping Definition 
Language (SMDL). SMDL is the base for both the textual 
schema mapping definition and the graphical user interface 
(GUI) schema mapping definition. The SMDL describes 
how schema are mapped in a textual format The Schema 
Mapper component of Smart Schema generates SMDL for 
the user so that the user does not have to learn a new 
language. Because the SMDL is in a textual format, it is 
completely portable. A parser is provided to translate the 
SMDL into SMIR (Schema Mapping Internal 
Representation). The SMIR is used by both the GUI schema 
mapping and run-time accessing the data store or object 
store. 

SMDL is designed to provide a schema mapping syntax 
that reduces the amount of work for the user and reduces the 
complexity of the schema mapping definition. The syntax is 
also designed to be easily extensible. 

A schema mapping definition describes how object 
schema and relational schema are mapped to each other. The 
object data model consists of interfaces, attributes, 
inheritance, etc; whereas, the relational data model consists 
of tables, columns, joins, etc. There are similarities and 
differences between these two data models. In SMDL, the 
similarities are mapped directly, while the differences are 
mapped using a specially created mapping syntax. 

4.2. SMDL Grammar 

The Schema Mapping Definition Language style is 
declarative and uses direct mapping based on key words. 
There are no intermediate models or constructs involved. 
The user sees only the object data model and the relational 
database model, and deals only with the constructs 
(interfaces and tables) in question. This strategy reduces the 
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amount of work for the user, reduces the complexity of the 
schema mapping definition, and increases the extensibility 
of the mapping syntax. 

The following is a high level description of the SMDL 
5 text grammar for schema mapping to map between relational 
database schema and object-oriented database schema. 
One SMDL file has one schema mapping definition. 
Schema mapping definition name must be unique. 
Only binary relationships are supported. 
The SMDL flow begins with the schema mapping name and 
10 narrows the scope with each mapping construct Within a 

schema mapping, there is connectivity information, 

classes and references. 
A class keyword defines its name, join condition, and its 

attributes. 

An attribute defines its type, table and column name, 

whether or not it is a primary key or allows nulls. 
A reference keyword defines its name, cardinality, to and 
from table and column names. 

The following is a high level description of the SMDL 
text semantics for schema mapping to map between rela- 
20 tional database schema and object-oriented database 
schema. 

Schema Mapping name must be specified in mapping defi- 
nition. 

Each statement starts with a keyword and has only one 
keyword. 

25 All keywords must be upper class characters. 

All the class definitions are followed by all the reference 
definitions. 

Attribute definitions start with the keyword ATTRIBUTE 
and end with keyword END ATTRIBUTE. 
30 Class definition starts with the keyword CLASS, embeds all 
attribute definitions, and ends with the keyword END_ 
CLASS. 

Reference definitions start with the keyword REFERENCE 

and end with keyword END_J*EFERENCE. 
Schema mapping definition is the highest level of the 

mapping definition. It starts with the keyword 
SCHEMA_MAPPING and embeds all class and reference 
definitions. 

indentation helps identify the hierarchy of the schema map- 
ping definition, but it is now required. 
40 The line starting with *#* character is handled as a comment 
line. 

4,3. SMDL Constructs 

The following sections describe the major language con- 
structs provided in SMDL and the purpose of each construct. 
45 An example is given for each construct 
4.3.1. Comment 

A comment starts with the # sign. Comments are line- 
based and can appear any where. A comment looks like the 
following: 

50 # This is a comment line. 4.3.2. Blank lines 

Blank lines are allowed to increase the readability of the 
schema mapping definition. Blank lines may appear 
anywhere, and they are ignored by the SMDL parser. 
4.3.3. Defining The Schema Mapping . 
A schema mapping definition starts with the keyword 

55 SCHEMA_MAPPING followed by the schema mapping 
name. The schema mapping name should be unique within 
a DatastoreMgr. A schema mapping definition ends with the 
keyword END_SCHEMA_MAPPING. The syntax is as 
follows: 

60 SCHEMA^MAPPING schema_mapping_name 
# Schema mapping definition 
END_S CHEMA_MAPPING 
43.4. Defining The Datastore Connection 
The datastore connection specifies the connection infor- 
65 mation for connecting to the relational datastore. The datas- 
tore connection should appear before the interface mapping 
definitions. 
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The datastore connection starts with the keyword -continued 

DAXASTORE_JD foUowed by the datastore identifier, or — ; 

datastore id, which is used for connecting to a datastore. The khy_type coiumu_type_i, coiumn_type_2, . . 

datastore id should be unique within the schema mapping ^° 1 ^r. typc -^. t . „ 

A^^i*s JOIN "join condition" 

to™*™' 5 SELECTION" filter condition^ 

The required arguments in the datastore connection are: orderby "order by clause" 

datastore type and datastore name. All other arguments are # 

optional and, if present, serve as default connection par am- * bc * ia attributc mapping definition 

eters. These optional arguments include: user_name and * " ; 4 . J ^ . . 

authentication. # end attribute mapping dcfiBition 

10 * 

Each argument starts with a keyword followed by the end_jnierface 

argument value. The syntax for the datastore connection ———————————————— 

definition is as follows: 

4.3.6. Mapping Attributes To Columns 
____ ^ — *° me attr i DUte mapping definition, no distinction is made 

DATASTORE-JD ny_ds_id 15 between columns and statistical columns (columns derived 

datastore_type db2/60oo from other columns). That is, columns are used to mean both 

D ATASTO RE__NAME my_ds_mmc columns and statistical columns. 

user_name my__name The mapping between attributes and columns is m-n, 

AUTHENTICATION abede which means one attribute may map to one or more columns 

endjatastoriljd and one or more attributes may map to a column. SMDL 

~-— m —^——- m ———--^^—-^—————— 20 supports three cases: 

43.5, Mapping Interfaces To Tables or Views ° ne ^ *> ^e column 

t«*i^;«*L*™ * a * j ^ ♦ J One attribute maps to multiple columns 

In the interface mapping definition no distinction is made Multi le attribut £ to ^ columfl 

between tables and views. That is, tables are used to mean Thfw ^^^L-^ * * . 

both tahlpc and vipwc ^ ™ sX ^ of mapping one attribute to one column is 

™^L^*£ZL • . rf a+u* • ... 25 a straight forward definition. The second and third cases 

The mapping between interfaces and tables is m-n, which require that user defined mapping functions be specified to 

™™\^ ^ OTe r ^t™^ ^ ° ne a " om P Hsh the appropriate ^ing. Tfcese two^ases as 

or more interfaces may map to one table. SMDL supports wcI1 as the user defined mapping functions are explained 

""^ cascs: below in Section 4.3,10 ("User Defined Mapping 

One interface maps to one table 3Q Functions"). 

One interface maps to multiple tables The attribute mapping definition includes the following 

Multiple interfaces map to one table ^formation: 

The first case of mapping one interface to one table is a t W c . A % 

straight forward definition. The second case of mapping one Table name, required only if the interface maps to multiple 

interface to multiple tables requires a join clause. Both of 35 *?bles 

these cases involve a single interface mapping definition. Column name 

The last case of mapping multiple interfaces to one table is Column type . 

accomplished through multiple interface mapping defini- f J 1 " 5 syntax for me attribllte mapping definition is as 

tions and by duplicating the table information in each ""lows: 
interface mapping definition. 

The interface mapping definition includes the following 40 attwbuie attribute^^ 

mformahon: ATnUBUTE-_TYEE attc_type 

acope or data manipulation and query for complex objects. table tabie^name 

A complex object is one which references other objects. column colunm__name 

The list of attribute names must be of interface type. column_ type coUypc 

Datastore id, which represents the connection information 45 ENP - ArnUBU1B 

for the datastore 



Table name, or table names in case the interface maps to 4.3.7, Mapping References Among Interfaces 

multiple tables t The mapping of references among interfaces, i.e. 

Key column names, which together uniquely identify the attributes of interface types, is defined using separate refer- 
persistent data and which are used in the generation of the so ence mapping definitions. For each reference, this involves 

data_Jd attribute for FID tw 0 sre p S . 

Key column types First a user specifies the reference name in the attribute 

Join condition, required only if the interface maps to mul- mapping definition. The syntax for doing is as follows: 
tuple tables 

Selection condition to restrict the set of tuples to be con- 55 ' 

sidered for each table, optional ATTRIBUTE attribute_nune 

Order By clause to order the result set of tuples, optional attributE-TYPE interk«_name 

The syntax for the interface mapping definition is as ™ R™^n^_name rel^amc 

follows: — 1KU3U1K 



60 



Second, the user specifies the reference mapping defini- 



JmB ^n^^^!Z C i ^ * ^ tion as described in ^e following section 33.7.1 ("Defining 

SCOPE — l, attributc_jianiG__2, . . the Reference Mapping"). 



attribute_name_l 



D atasto RE_ID my_ds_jd 4.3.7.1. Defining Hie Reference Mapping 

table tabie_namc_i 7 tabie_namc_2, . . ., tabie_jiame_jn The information used for defining the reference mapping 

KEY cofomn_nanv:_i, cohimn_jiamc_2 1 . . 65 comes from the foreign key to primary key relationship as 
cohima_n 2 nie_ji this relationship appears in the relational datastore. This 

foreign key to pimary key relationship may appear directly 
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from the source table(s) which contains the foreign key, to 
the target table(s) which contains the primary key. 
Alternatively, this relationship may appear indirectly 
through a relationship table. The direct foreign key to 
primary key relationship may represent a 1-1 relationship or 
1-m relationship, but an indirect relationship table may 
represent an m-n relationship. 

A major benefit of reference mapping is that, since the 
foreign key to primary key relationship as it appears in the 
relational datastore is used, referential integrity may be 
maintained in the relational datastore. Referential integrity 
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Target relationship column names, the number and sequence 

of which must match with those of the key column names 

of the target interface mapping definition 
Target relationship column types, the number and sequence 

of which must match with those of the target relationship 

column names 

The indirect reference mapping syntax is as follows: 



REFERENCE rcfcrcncc_oamc 
FROM^JNTERFACE mterface_name 
FROM_AlTTRIBUTE attribute _namc 
REL_TABLE table_name 

REL^_COLUMN c olumn ( _name_ 1 , co hmm_joame_2, . . ^ c olumn L _name__m 
REL._COLUMN_.TYPE column_type_J, cohimn_type__2 T . . colunm_typc_m 
TO_JNTERFACE interface_name 
REL_TABLE tablcjuame 

REL_C OLUMN column_name_l, cohimn l _name_2 T . . ^ columA_name_ji 
REL_COLUMN_TYPE cotoinn_.type_J, colunm_typc_2, . . column_type_ji 
END_REFERENCE 



means that every foreign key in a table must refer to an 
existing key in the related table, or it must be NULL, which 25 
means that it does not refer to any key in any table. 
4.3.7.2. Defining The Direct Reference Mapping Without A 
Relationship Table 

The direct reference mapping definition includes the 
following information: 

Source interface name 30 
Source attribute name 

Source table names, which must be a subset of the table 
names which appear in the source interface mapping 
definition 

Source column names, the number and sequence of which 35 

must match with the those of the key column names of the 

target interface mapping definition 
Source column types, the number and sequence of which 

must match with those of the source column names 
Target interface name 

The syntax of the direct reference mapping is as follows: 40 



REFERENCE Kference_name 

FROM_JNTERFACE i_cr£acc_name 
FROM_AITRIBinE attribute_name 

FROM—TABLE table_jiame_l, tabk_name_2, . . 45 
table_name_jn 

FROM—COLUMN columiLjiarne 1, column_uame_2, . . 

f-f1" m T T| narrw. n 

FROM_COLUMN_TYFE column_type_l, coIunm_type_2, 
. - coIumn_Jype_n 

TQ_JNTERFACE interface _name 50 
END_REFERENCE 



4.3.7.3. Defining The Indirect Reference Mapping With A 
Relationship Table 

The indirect reference mapping definition in this case 55 
includes the following information: 
Source interface name 
Source attribute name 
Source relationship table name 

Source relationship column names, the number and m 
sequence of which must match with those of the key 
column names of the source interface mapping definition 

Source relationship column types, the number and sequence 
of which must match with those of the source relationship 
column names 

Target interface name 65 
Target relationship table name, which is the same as the 
source relationship table name 



4.3.8. Union, Intersection, and Difference 

Union, intersection, and difference may be used in schema 
mapping. If the user wants to collect data into the same 
collection from a set of different tables, the union function 
may be used. For example, the employee tables are split into 
several geographical areas and mapped into one class by 
using the union syntax below. These three operations (union, 
intersection, and difference) have a similar schema mapping 
syntax. 

4.3.8.1. Union For Class Mapping 

T he desi red keyword, either UNION, INTERSECTION, 
or DIFFERENCE, is substituted for "UNION" in the syntax 
as follows: 



Vbegin{ verbatim} 
CLASS classLjaanv 

JOIN "join syntax*' 

CONDITION "condition syntax" 

ATTRIBUTE attribute _name 

ATOUBUTRJTYFE attribute__type 

TABLE table—name (or view _jiame) 

COLUMN Colmna_namc (or statistical col umn nam e) 
(, column_name [for multiple columns]) 

TYPE column_type 

PRIMARY_KEY (yes or no) 

PRIMARY_KEY_SEQ sequencc_jiumbcr 

DEFAULr_NULL_VALUE derault_null_value 

END_ATTRIBUTE 

ATTRIBUTE attribute_naine2 

ATTRIBUTE_TYPE attribute__type 

TABLE table__namc (or vicw__name) 

COLUMN oolumn_name (or statistical col umn _n3rrn » ) 
(, column narnr [fox multiple col umns ]) 

TYPE column_type 

PRIMARYJKEY (yes or no) 

PRIMARY_KEY_SEQ sequenrc^umber 

DEFAULT_J^ULL_VALUE derault_nuU_vahje 

END_ATTRrBUTE 

UNION 

JOIN "join syntax" 
CONDITION "condition syntax" 
ATTRIBUTE attribute_name 
ATTRffiUTE_TYPE attribuie_type 

TABLE table_name (or view name) 

COLUMN col umn namir (©r statistical_columix_iiame) 

(, coIumn_name [far multiple columns]) 
TYPE cohnnu_typc 
PRIMARY__KEY (yes or no) 
PRIMARY_JCEY_SEQ 6equence_numb<;r 
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DEFAULT_J*ULL_VALUE default_null_value 

END_ATTRIBUTE 

ATTRIBUTE attribute_name2 

ATTRIBXJTE_TYPT attribute-type 

TABLE table_name (or view__name) 

COLUMN column— name (or statistkal— column__name) 
(, column__naine [for multiple columns]) 

TYPE coIumn_type 

PRIMARY-KEY (yes or no) 

PRIMARY—KEY— SEQ sequeoce_numbcr 

DEFAULT_NUIX_VALXJE defaulL_nuIL_Vahie 

END_ATTRtBUTE 
END_CLASS 
\cnd{vcrbatim} 



In the above syntax, the user must repeat information 
while keeping it consistent; therefore, an alternative syntax 
may be provided. This alternative syntax emphasizes union 
(or intersection or difference) in the attribute instead of in the 
class. Again the desired keyword (UNION, 
INTERSECTION, or DIFFERENCE) may be substituted for 
the correct function in the syntax as follows: 



\begin{verbatim} 
CLASS class_name 

JOIN "join syntax" 

ATTRIBUTE attribute— name 

ATTRIBUTE— TYPE atmbute_type 

TABLE table_name (or view__name) 

COLUMN column_name (or statistical— column_name) 
(, column_naine [for multiple columns]) 

TYPE column— type 

UNION 

TABLE table_name (or view_name) 

COLUMN Column_namc (ox statistical col nmn natw ) 
(, column__name [for multiple columns]) 

TYPE column— type 

END_ATTRIBUTE 
END_CLASS 
\end{ verbatim} 
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In this alternative syntax, although the user does not have 
to repeat information* the user is not able to give a different 
join clause for each union. 
4.3.8.2 Union For Reference Mapping 

The syntax for union for reference mapping is as follows. 
Note that intersection and difference functions for reference/ 
relationship mapping has no semantic meaning; therefore, 
only union is supported. 



Ybegin{vert>atim} 

RELATIONSHIP rclatioDsbip__namc 
FROM rc fercnce_quantity (t 0 r n) 
FROM-CLASS class_namc 
FROM_jOTRIBUTE attribute_name 
FROM_ATTRIBUTE_TYPE attribute_type 
FROM__TABLE table_name 

FROM_C QLUMN column— name, column— name2, . . . 
FROM_COLUMN_ TYPE column_typc, 
column .type2, . . . 
TO refero^— quantity (1 or n) 
TO_CLASS class_namc 
TO_ATrRIBtrrE attribute __name 
TO_ATTRIBXrrri_TYPE attributc_typc 
TO TART .R table— name 

TO__COLUMN columa_name, column__name2, . . . 
TO_COLUMN— TYPE column— type, column— type2, . . 
UNION 

FROM reference— quantity (1 or n) 
FROM-CLASS class_jiame 
FROM^ATTREBUTE attribute _name 
FROM_ATTRIBUTE_.TYPE attribute_typc 
FROM_TAHLE table_name 
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FROM— COLUMN column_jiamc t colunuLJiame^ , . . 
FROM_COLUMN_TYPE column— type, 
ccdumn— type2, . . . 
TO reference—quantity (1 or n) 
TO.JXASS class _name 
TO_ATTRIBTJTE attribute_name 
TO_j\TTRIBUTE_TYPE attribute— type 
TO„TABLE table— name 

TO COLUMN colunm_joame, column— name2, . . . 

TO_COLUMN_TYPE column_type, column— type2, . . 
END— RELATIONSHIP 
\end{verbatim} 



An alternative syntax may also be provided. This alter- 
13 native syntax emphasizes union in the attribute instead of in 
the reference/relationship. 



\be£in{verbatim} 
REFERENCE ieference_name 
FROM re£erence__quantity (1 or n) 

FROM— CLASS cbss_namc 

FROM^ATTRIBTJTE attribute_name 

FROM_ATTRIBTJrE_TYPE attribute_typc 

FROM—TABLE table_name 

FROM— COLUMN column— name, column__nanie 2 , . . . 
FROM— COLUMN—TYPE column— type, cohimn_typc2, . . . 
UNION 

FROM—TABLE table_name 

FROM— COLUMN column— name, column— name2, . . . 
FROM— COLUMN— TYPE colwnn_rype, cohmm_tvpe2, . . . 
TO reference_quantity (1 or n) 
TO_jCLASS class_name 
TO— TABLE table— name 

T0_ COLUMN column— name, cohimn_joame2, . . . 

TO_COLUMN_TYPE column— type, column— type2, . . . 
END_REFERENCE 
\end{ verbatim} 
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The limitation of this alternative syntax is that it can not 
describe a mapping where the first part of the union uses a 
foreign key and primary key relation, while the second part 
of the union uses a relationship table. 
4.3.9. Defining Inheritance Mapping 
40 In the object-oriented model, a class inherits from its 
superclasses. Hie superclass is mapped to some tables like 
any other class, but the subclass needs only to map the 
attributes that are not part of its superclasses. Therefore, 
there is no need to repeat any part of the superclass mapping. 
The keyword SUPER\_CLASS indicates the superclass 
45 inheritance for the subclass. If the user needs to join tables 
for the superclass and tables for the subclass, the keyword 
SUPER\_JOIN is used. The remaining part of the class 
mapping is same as a normal class. 
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\begin{verbatira} 
CLASS class—name 

SUPER_CLASS superclassLjaame 
SUPER— JOIN "join syntax" 
JOIN "join syntax" 
ATTRIBUTE attribute __nome 
ATnUBUTE_TYPE attribute_type 
TABLE table— name (or view— name) 
COLUMN column— name (ox statistical— column— name) 
(, cotumn_name [for multiple columns}) 
TYPE column— type 
END— ATTRIBUTE 
END-CLASS 
\end{verbatim} 



4.3.10. User Defined Mapping Functions 
User defined mapping functions allow the user to code 
65 transformations for ENUMs and other types. They also 
provide a way for the user to split one column into multiple 
classes. SMDL supports three cases: 
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The function is applied to one attribute. 
The function is applied to multiple attributes. 
The function is applied to a reference/relationship. 
4.3.10.1. An Exit Function For One Attribute 

This exit function is applied to only one attribute; 
therefore* the exit function name is specified in the attribute 
mapping. 



\begin{verbatmi} 
CLASS class_name 
JOIN "join syntax" 
ATTRIBUTE attribute_jiame 
ATTRIBUTE_TYPE attribute_type 
TABLE table_name (or view _namc) 

COLUMN column__naxne (or statistical column_naiae) 

(, column__name [for multiple columns]) 
TYPE column__typc 
EXTT^pUNCTION fmction_jiame 
END__ATTRIBUTE 
ENIL_CLASS 
\cnd{Ycrbatim} 
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\begin{verbatim} 
CLASS clas3_name 
JOIN "join syntax" 
5 ATTRIBUTE attribute.. name, attribute_name2, . . . 

ATTRJBUTE-_TYEE attribute_typc t attribuie_type2, . . . 
TABLE table__name (or view _name) 
COLUMN oolumn__name (or statistic aI_column_namc) 
TYPE coluam_type 
EXTC-FUNCTTON functiou_name 
10 END_ATTRJBIJTE 
END_CLASS 
\cnd{ verbatim} 



Alternatively, an exit function may be specified for mul- 
15 tiple attributes. In this case, the user may create a function 
for each attribute, and name the function in each attribute 
mapping using the syntax described for an exit function for 
one attribute. 

43.10.3. An exit Function For A Reference 
20 When the exit function is applied to a reference or a 
relationship, the exit function is specified in the reference or 
the relationship mapping as follows: 



\bcgin{vcrbatira} 

RELATIONSHIP relationship _name 

EXrr_REL_FUNCTION function_jian* 
FROM reference_quantity (I or n) 

FROM_CLASS cjas^jwrnt 

FROM^TTRIBUTE attribute_name 

FROM_jVTITUBUTE_TYPE attribute_type 

FROM_TABLE table_name 

FROM_COLUMN column_jiaine, cohann_nanie2, ... 
FROM_COLUMN_TYPE column_type, column_typc2, . . . 
FROM—RELTABLE table__name 

FROM_RELCOLUMN cohnan_name, column_jiame2, . . . 
FROM_RELCOLUMN_TYPE columo_tvpc, column_typc2, . . . 
TO reference__qaanlity (1 or n) 

TO_CLASS class__name 

TO^ ATTRIBUTE atrriburc_jiarre 

TO^ ATTRJBUTE_TYEE alL_tribute_type 

TO_TABLE tablc_jiamc 

TO_COLUMN colummiame, columa_name2, . . . 
TO_C OLUMNTYPE column_typc, column_typc2, . . . 
TO_RELTABLE table name 

TO_RELC OLUMN column__Ban», column_name2, . . . 

TO_RELCOLUMN_TYPE columa_type, column_typc2, . . . 
END_RfiLATIONSHIP 
\eod{ verbatim} 



4.3.102. An Exit Function For Multiple Attributes 



If multiple data members map to one column, these data 50 
members are listed in the attribute list. The syntax for the 
multiple data member mapping is as follows: 



\begin{verbatim} 

ATTRIBUTE attribubc_namel, attribute_name2, . . . 

ATTTUBUTE_TYFE attribute__typel f attribute_type2, . . . 

TABLE table_name (or view_name) 

COLUMN column_name (or statistical_cohmm_name) 

TYPE column_rypc 
END_ATTRIBUTE 
\end{verbatim} 



4.4. The BNF grammar of SMDL 

If the exit function is applied to these multiple attributes 65 
in a class, then the exit function is specified in the class The following is a Backus Normal Form (BNF) grammar 
mapping as follows: description of the Schema Mapping Definition Language: 
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\input{gramniar} 
\bcgin{verbatim} 

# schema mapp ing grammar 

<SCHEMA__MAPPING>: :<C0MMENT_3IAPPING_S> 
SCHEMA_MAPPING schcma_mapping_namc 

<DAEABASE-MAPPING_S> 

<CLASS_MAPF1NG_S> 

<REFERENCE_MAFPING_S> 
<COMMKNX_MAPPING_S>::<COMMENT — MAPPING_S> <COMMENT_MAPPING_S> ] 

<COMMENT_MAPPINO> 
<DAIABASE_JVIAPPING_S>::<I)AIABASE_31APPING_S> <DATABASE_MAPPING__S> ] 

<DATABASE_MAPPING> ] null ] 

<C0MMENT_31APPING_S> 
<CLASS_MAPPING_ S>::<CLASS_MAPHNG_S> <CLASS _MAPPING_S> ] 

<CLASS_MAPFING> ] <COMMENT_MAPPING_S> 
<REFERENCE _MAFPING_S>: : 

<REFERENCE_MAPPING_S> <FEFERENCE_MAPPING_S> ] 

<REFERENCE_MAPPING> ] null ] <COMMENT_JvlAPPING_S> 
^comment grammar 

<COMMENT_MAPFING>! :#ccrmmeDOine ] blank^Jine 

# database grammar 

<DATABASE_MAPPING>:J)ArASTORE database_name 

(<DATABASEL-ARGUMENTS>) 

END_D ATASTO RE 
<DATABA5E_JUIGUMENTS>::<DBMS_VALUE> 

<DB_VALUE> 

<CONNECnVTTY_VALUE> 

<ACCESSMETHOD_VALXJE> 

<USERID_VALUE> 

<PASSWORD_VALUE> 
<DBMS_VALUE>: iDBMS dbms_value 
<DB_VALUE>::DB db_vahie 

<CONNECTIVnT_VALUE>: :C0NNECHV1TY conn©ctivity_value 
<ACCESSMETHOD_VALUE>: ACCESS 3ccessmethod_vame 
<USERID_VALUB>: :USER_JD user_id 
<PASS WORD_VALUE>: PASSWORD password 
ifenumerate grammar 

<ENUl^RATE - JrfAPPING>: ENUMERATE cnuincrate_iunctiQa_jiame 

(<ENUMERATE_jyiGUMENTS>) 
<ENUMERATE ARGUMENTS>: :<REL_ENU\1__VALUE_PAIR_S>, 

<CXASS_ARGUMEN1>,<ENUM--TYPE^ARGUME^ 

<TVALUE_TYPE_ARGUMENT> 
<3tEI L _ENU\LA r ALUE^AlK^ 
_VALUB_PAIR_S> ] 

<REL_ENW_VALUE_PAIR> 
<REL^nJ\l_VALUEJAIR>::rchtioiiaLvaliB ( c^^ 
<CLASS_JVROUMENT>;:CLASS class_name 
<ENU^TYPE_JUIGUMENT>:£NUM_TYPE ennm_type 
< VALUE_TYPE_ARGIJMENT>: : VALUE_type value_type 

# class grammar 

<CLASS_MAPPING>:KXASS classL_name 

{<SUPERCXASS_JvIAPPING>} 

{<JOIN_VALUE>} 
(<DAJAMEMBER_MAPPING_S>) 
END_CLASS 

<SUPERCLASS_MAPPING>: :<SUPERCLAS S_NAMES> 

<SUPERJOIN_VALUE> 
<SUPERCIASS_NAMES>::SUPER_CLASS $uperclass_name 
<SUPERJOIN„VALUE>: :SUPER_JOIN <JOIN_SYNTAX> 
<JOIN_SYNrAX>::"join_synta]c" 
<J0IN_VALUE>::JOIN <JOIN_SYNTAX> 

# data member g^rnnriftr 

<I)ATAMEMBER_31APPING_S>::<3)ATAMEMBEP^31APPING_S> 
<DATAMEMBER_31APPING_S> ] 

<DAXAMEMBER_31APPING> ] <S _JDATAMEMBER__MAPPING> ] 

<DUMMYJAIAMEMBER_MAPPING> 
<D ATAMEMBER_MAPPING>: lATTRIBUIE data — mcmber_jume 

<ATIWBUIE_TYPE_VALUE> 

<IABLE_VALTJE> 

<COLUMN_VALUE> 

<COLUMN_TYPE_VALUE> 

{<SEQUENCE_VALUE>} 

{<BEFAULT_VALUE> } 

{<EXTT_FUNCnON_VALUE>} 

END_AITRIB"tnE 
<TABLE_MAPPING>::TABLE table_aame 
<COLUMN_S_3IAPPING>: icolumn^name ] 

(<COLUMN_NAMES> {, <PRIMARY_VALOE>} {, <SEQUENCE_VALUE>} 

{, <DEFAULT_VALUE>} {, <EXIT_JUNCT10N_VALUE>}) 
<COLUMN_MAPPING>::COLXJMN column_name 
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<COLUMN_J^AMES>: :<COLUMN_JS T AMES>,<COLUMN_JJAMES> ] colunm_name 
<PRIMARY_VALUE>: PRIMARY <PRIMARY_VALUE_NAME> 
<PRIMARY_VALUE_NAME>::ycs ] no 
<SEQUENCE_VALUE> : : SEQUENCE sequen«L_Dumber 
<DEFAXJLT__VALUE>: : DEFAULT defaulL_value 

<aDEFAIJLT_JWCTION>::DEFAUU , _FUNCTION de£ault_functioiL_iiame 
<EXrr_PUNCTION_VALUE>: JUNCTION 6xit_funjctioQ_name 
<REFERENCE_NAME>: :<REFERENCE__N AME> OR <REFERENCE__NAME> ] 
rcfcrcncc_name 

<S_DATAMEMBER_MAPPING>: :<D AlAMENmER^AMES>^IABL£_J^APPING>.<COLUMN 
N_MAPPING> 

<DATAMEMBER^AMES>::<0XA1AMEMBER^AME^ ] 

ffatamftmhft T pamr 

<I)UMMY_JDATAMEMBER_JVlAPPING>: : $$DUMMY$$=^TABLE_MAPPING>.< 

COLUMN_JMAPHNG> 

# reference grammar 

<KEFERENCE_MAPPING>: :REFERENCE relationship_name 
{<EXrTJFUNCTION_ARGUMENT>} 
<FROM_REFERENCE_ARGUMENTS> 
<TO_REFERENCE __ARGUMENTS> 
END_REFERENCE 
<FROM_REFERENCE_ARGUMENTS>: :FROM refcrence_quanlity 

<FROM_CLASS_jVRGUMENT> 

<raOM w JtfTRIBt)TE __ARGUMENT> 

<FROM_ATTRIBUTETYPE__ARGUMENT> 

<FROM_TABLE_ARGUMENT> 

<FROM_COLUMN_JVRGUMENT> 

<FROM_COLUMNTYPE_jUlGUMENT> 

{<raOM_OPTIONAL_ARGUMENTS>} 
<FROM_OraONAU^GUMENTS>::<FROM_JlEIT^ 

<FROM_RELC OLUMN__ARGUMENT> 

<FROM_RELC OLlJMNTYPE_ARGlJMENT> 
<TO_REFERENCE__ARGUMENTS>: :TO refereDce_quantily 

<TO_CLASS_^ARGUMENT> 

<^_AITRIBUTE_ARGIJMENT> 

<TD_jVTTRIBUTETYPE_JVRGUMENT> 

<TO_TABLE_ARGUMENT> 

<TO_COLUMN_ARGUMENT> 

<T0_COLUMNTYPE_ ARGUMENTS 

{<OX)_OPTIONAL_ARGUMENTS>} 
<rrO_OPTIONAL_^RGUMENTS>: :<aX3_RELTABLE_ARGUMEKI> 

^_jyaLCOLUMN_ARGUMENT> 

<TO_REL£OLUMNTYPE __ARGUMENT> 
<FRON1_<XASS_^GUMENT>:lFROM_CLASS classL-aame 
<FROM^ITmUTE_ARGUMENT>::FllOM^ afiribute_name 
<3^0M_jyTRJBUTETYPE_j\RGUMENT^ attribute_type 
<FROM^TABI^_^GUMENT>:OTIOM W .TABLE table_jaame 

<FROM-COLUMN ARGUMENTS: JRQM CQTJTTMV fnlnmn nor^ 

<FROM_COLUMNTYPE_ARGUMENT>: fROH_COLUMN_TYPE cohnnn_type 
<FROM_RELTABLE_^ARGXJMENT>: lFROM_RELTABLE table_name 
<FROM_RELCOLUMN_ARGUMENT>: :FROM_RELCOLUMN column_name 
<FROM_REIX:OLUMNTYPE_J\JlGUMENT>: :FROM_RELCOLUMN_TYPE columa_type 
<TO_CLASS_ARGUMBm>: :TO_CLASS class_nanie 
<TO_AriTUB UTE_A RGlJMENT>: :TO_ATTRIBUTE attributc„name 
<TO_^ATTR1BITIETYPE W ARGUMENT>: :TO_ATTRTflUTE_TYPE attribute_type 
<lO_TABI^_JVRGUMENT>::T0_TABLE table_name 
<TO_COLUMN_ARGUMENT>: :TO_COLUMN oolunm_name 
<TO_COLUM^mfPE_J^RGUME^^^>: :TO_COLUMN_TYPE Column_type 
<TO_JRELTABLE — ARGUMENT>: rTO_RELIABLE table_name 
<^_RELCOLUMN__ARG1JMENT>::TO_JIEIXOLUMN colmnn_name 
<OXD_REIXOLUMNTYPE_jUlGUMENT>: :TO_RELCOLUMN_TYPE cohima_type 
\end{verbauin} 



5. Code Generation 

Once the data store schema is mapped to the object 
schema, the user may use code generators 410 or 420 to 
generate data access methods for each object interface. For 
example, the user may have created classes MyEmp and 
MyDept, created tables EMP and DEFT, and mapped 
MyEmp to EMP and MyDept to DEFT with the following 
mappings: 



55 



Attribute Type Column Type 



MyEmp Class to EM P Table mapping 

EMPNAME siring EMPNAME char 

EMPNO long EMPNO integer 

WORKDEPT bog WORKDEPT integer 

MyDept Class to DEFT Table Mapping 

DEPTNAME string DEPTPNAME char 

DEPTNO long DEPTNO integer 
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To generate SOM IDL, for example, the user may select 
a MyEmp class icon in a Smart Schema window to display 
a popup menu containing a Generate Access Methods menu 
item. The user may then select the Generate Access Methods 
menu item to display a list of options such as SOM, C++, 
SmallTalk, etc. The user may then select SOM to generate 
all the SOM related files. The user may then repeat this 
process for the MyDept class. 

The code generator generates the following files for the 
MyEmp class and the MyDept class when SOM is selected: 



MyEmp Files 


MyDept Files 


Purpose 


myempidl 


mydept.idl 


DDL file containing data 






access methods fox the 






class 


myempxpp 


mydeptxpp 


SOM C++ method 






implementation 


myemp^qc 


mydeptsqc 


SQL statement that needs 






to be pre-processed 


myemp.mak 


mydeptmak 


Makefile for building the 






class 
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// ClientDataStoreMgr IDL Description 

interface ClientDataStoreMgr : SOMObject 

. { 

void conncct(in DatastoreConnection connection, 
in string datastore_id, 
in string U3cr__namc, 
in string authentication); 
void disconoect(in DatastoreConnection connection); 

void transact(in UscrEnvironment user envir, 

in short completk>n_type); 

}; 

// DatastoreConnection IDL Description 

interface DatastoreConnection : SOMObject 
{ 

void seL_option(in long option, in any value); 
void get_opt»n(Ln long option, out any value); 

}; 

// UscrEnvironment IDL Description 

interface UserEnviraiiment : SOMObject 
{ 

void sct_optiou(in long option, in any value); 
void get_option(in long option, out any value); 
void release s( ); 



The myempidl file is listed below: 



include <&omobj.idL> 
interface MyEmp : SOMObject 
{ 

attribute string <20> EMPNAME; 
attribute long EMPNO; 

attribute long WORKDEPT, 30 
void add( ); 
void update { ); 
void del( ): 
void retrieve( ); 

#ifdeL_S OMIDL_iniplenieiLta£ ion 

{ 35 
releascctrder : 

_get_EMPNAME, __set_EMPNAME, 
_get_EMPNO, _seLJEMPNO, 
_gcC_WORKDEPT, _set_WORKDEPT, 
add, 
upda^ 

del, 40 
retrieve; 

}; 

#endif 

}; 



Two constructors are generated, one is a default 
constructor, and the other one initializes all the data mem- 
bers of the class. The data members correspond to the 
columns in the table. 
Four data access methods are generated: 30 
add() to add a new instance to the BMP table; 
update() to update an existing instance in the EMP table; 
del() to delete! an instance from the EMP table; and 
retrieve() to retrieve an instance by key from the EMP 
table. 

After the user has generated the SOM classes, a Data 
Store Manager provides the following IDL interfaces and 
implementations that may be used to connect to and perform „ 
transactions in the data store: 

ClientDataStoreMgr; 

DatastoreConnection; and 

UserEnvironment 

The IDL interfaces and descriptions of 65 
ClientDataStoreMgr, DatastoreConnection, and UserEnvi- 
ronment are as follows: 



A sample SOM base client application using the above 
IDL interfaces to connect and perform transactions in the 
data store is as follows: 



// Sample SOM Base Client Application 
// To connect to the data store 

Environment *ev; 

DatastoreConnection *dsc; 

ClientDataStoreMgr *dsm; 

ev = &omeGetGk]baIEnvironment( ); 
// Create Datastorc connection object 

dsc = new DatastoreConnection; 
// Connect to Datastorc 

dsm - new ClientDataStoreMgr, 

dsm->connect(ev, dsc, "datastorc id", "chris", "password"); 
// To add a new MyEmp and MyDept object 
MyDept »dept; 
MyEmp *emp; 
dept = new MyDept; 
emp - new MyEmp; 
// lb add a MyDept object 

dept->seL_DEPTNAME(ev, "ADTC") ; 

Qept->seUDEPTNO(ev, 846); 

dept->add(ev); 
// To add a MyEmp object 

emp->set_EMPNAME(ev, "Dex"); 

emp->seLJEMPNO(ev t 103); 

emp-Xict_WORKDEFr(ev, 846); 

emp->add(ev); 

// To update an existing MyDept object with key value 123 

dept-set_DEPTNO(cY, 123); 

dept->set_DEPINAME(ev, **ADTT'); 

dept->update<ev); 
// To retrieve an existing MyEmp object with key value 70 

emp->seUMPNO(ev, 70); 

emp->tetrieve(ev); 
// To delete an existing MyDept object with key value 123 

dcpt->set_DEPTKO(eY, 123); 

dept->del(ev); 

// To commit transactions and disconnect from the datastorc 
dsm = transact(ev, ue, "COMMIT*); 
dsm— >disconnect(ev, dsc); 



Once the user has developed a client application such as 
the one above, the user may compile and link the client 
application with the appropriate run-time (for example, a 
SOM run-time library, C++ run-time library, SmallTalk 
run-time library, etc.). 

Although the above preferred embodiment is described 
primarily relative to mappings between object schema and 
relational data stare schema, the teachings of this preferred 
embodiment may be extended to provide alternative 
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embodiments which also provide mappings between object 

schema and other non-relational data store schema, . 

including, but not limited to, hierarchial data store schema, interface interface_mme 

flat file data store schema, network data store schema, and scope attribute_jiame__i 1 attribute_namc_2, . . ., 

object data store schema. In these alternative embodiments, 5 McSraMLro ds_id 

the teachings of the Smart Schema may be extended to SEC3MENT S c X _Jdu7««_«L^ . . seg_kL_m 

support the display, selection, mapping, SMDL generation, key field_name_i, fiekUname_2, . . ., ficld_name_a 

SMIR generation, and code generation required for these KEY_TYPE field_type_i, ffel(Ljtype_2, . . fickl_typc_n 

other types of non-relational data store schema. Similarly, # 

the teachings of the Smart Access, SMDL, SMIR may also # ^ attribulc capping definition 
be extended to support these other types of non-relational 10 * ^ attribute . definMo|i 

data store schema, # 

For example, in an alternative embodiment supporting end_jntbrface 

hierarchial data stores, Smart Schema may be modified to — — — ^— ^— 

display and select hierarchial data store schema. Schema ™ ATmmiFrr ..~ J4 . 

M^mayfaeinodtfirt^ 15 ™!> ATTRIBUTE consfruct may be mc^ed by adding a 

to hierarchial schema. SchZ Mapper maybe^ further ^ h k ;S 

mc^edtoa^ SftS^^ 

and object classes, the mapping between hierarchical For sucn a hierarchial ATTRIBUTE construct, the FIELD 
schema segments and object schema interfaces, and the argument list may include sufficient rnerarchial descriptors 
mapping between hierarchial schema fields and object 2 o to identify the data, such as pcb_name, seg_jiame, field_ 
schema attributes. type, field_Jength, and field_offset. In addition, a CONV 
Such an alternative embodiment of the Schema Mapper keyword may be added to specify the data conversion 
may support the following mappings: method, method _name, to be used for converting between 
Hierarchial Data Schema (HDS) to Class hierarchial data types and object data types. These modifi- 
One HDS to one class 25 cations yield the following hierarchial ATTRIBUTE con- 
One HDS to many classes struct: 
Many HDS's to one class 

Class to HDS — Z — " 

^ « . „_„ ATTRIBUTE attribute_nairc 

One class to one HDS attribute__type attr_typ= 

One Class to many HDS 30 FIELD pcb_name scg_psmc field_type fi«ld_length 

Many classes to one HDS field_offset 

Field to Attribute end^S^ 

One field to one attribute _ ^ 
One field to many attributes 

Many fields to one attribute 35 The Schema Mapper may also provide datatype 

Attribute to Field mappings, both default and allowable, between hierarchial 

One attribute to one field datatypes and object datatypes. Table 7 lists and describes 

One attribute to many fields ^ defi *f d * «» hierarchial data store, IBM 

Many attributes to one field J* S^^J 1 ^ * W S 

Definition Language is weU suited to adding additional P ShaiiBI \y, me t ^ chin of me Smti Access> code 

constructs or modifying existing constructs to support such , 7. 5 _ jiumi nvww, wuc 

hiWamhioi ma mi«iu, c*JL r»^K^„ to" generation, and run tune support may also be extended to 

toerarchialma^ 45 te Qfh «^ non ^ elational ^ store 

guage constructs may be modified or extended as follows. sc hema 

The DATASTORE construct requires no modification, Pm; ' nfl < Ua «u,™ ol . ... . 

only the specification of a m^cliial data store type, IHDS/ ^ ^ 1 * e , ab ° vc Raiment supporting 

IMS for example, instead of a relational SS^SSt^T ta ~^ ^ ta sto / cs ' * c j^S 5 of . *« Referred 

1^ , iu a *au V i « iwauuuai uoi* awie t /F c. embodiment may be extended to provide alternative 

• 50 embodiments which also provide mappings between object 

DATASTOREJD my_ds_id schema and flat file data store schema, mappings between 

datastore_type ihds/zms object schema and indexed file systems data store schema, 

D atasto re_n ame my_ds_name (DBNAME or mappings between object schema and network data store 

PSBNAME) schema, and mappings between different object data store 

USER_NAME my_jwme schema 

AUTHENTICATION abede 35 TT . " . ^ . 

end_jd atasto re_js using the foregoing specifications, the invention may be 

— implemented using standard programming techniques. The 
resulting programs may be stored on disk, diskettes, memory 

The INTERFACE construct may be modified by adding a cards, ROM or any other memory device for use in a 

SEGMENT keyword and its list of segments, wherein the computer. For execution, the program may be copied into 

SEGMENT keyword is only applicable when the 60 the RAM of the computer. One skilled in the art of computer 

DATASTORE_TY PE is a hierarchial data store type. For science will easily be able to combine the software created 

such a hierarchial INTERFACE construct, the KEY list is a as described with appropriate general purpose or special 

list of hierarchial field names instead of a list of column purpose computer hardware to create a system for executing 

names as in the relational case. Similarly, the KEYJTYPE the programs. While the preferred embodiment of the 

list is a list of hierarchial field types instead of a list of 65 present invention has been illustrated in detail, it should be 

column types as in the relational case. These modifications apparent that modifications and adaptations to mat embodi- 

yield the following hierarchial INTERFACE construct: ment may occur to one skilled in the art without departing 
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from the scope of the present invention as set forth in the 
following claims. 

TABLE 1 
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TABLE 3 -continued 



ODL Data 



ODL Type 



Description 



5 ODLTVpc 



ODL to SQL Data Type Mapping 
SQL Type 



long 


range -231. . .231-1 


unsigned long 


range 0. . .232-1 


short 


range -215. , .215-1 


unsigned short 


range 0. . .216-1 


float 


IEEE single-precision floating point numbers 




double 


double 


IEEE double-prec is ion floating point numbers 


char 


8-bit quantity 


boolean 


TRUE FALSE 


octet 


8-bit quantity mat is guaranteed not to 




undergo any conversion when transmitted 


any 


any ODL type 


struct 


similar to C/C++ struct 


union 


a cross between C union and switch 


cnum 


similar to C/C++ cnum 


sequence<rype, 


"type** specifies any ODL type. 


n> 


M n" specifies the ipaytmiini size of the 




sequence and is optional 


string<n> 


**n" specifies the maximum size of the string 




and is optional. 


array 


niuhi^dimensional, fixed-size array 


interface 


a type that is satisfied by any object that 




satisfies a particular interface 


TABLE 2 




SQL Data Types 


SQL Type 


Description 


CHAR(n) 


fixed length character string (1. . 254) 


VARCHAR(n) 


varying-length character string 




(I. . .4000) 


LONG VARCHAR 


long yarying-length character string 




(1. . .32700) 


GRAPHtC(n) 


fixed length graphic string - DBCS 




(i. .127) 


VAKGRAPHIC(n) 


varying-length graphic string - DBCS 




(1. .2000) 


LONG VARGRAFHIC long varying-kngth graphic 




string - DBCS (1. .16350) 


BLOB 




SMALLENT 


small integer (-215. . .215-1) 


INTEGER 


large integer (-231. . .231-1) 


REAL 


a 32 bit approximation of a real number . 


FLOAT 


a 64 bit approximation of a real number 


DECIMAL<p,s) 


**p" specifies the precision which 




can be from 1 to 31. 




**s" specifies the scale which can be less 




than or equal to "p". 


DATE 


10 byte character string designating 




(year, month, and day) 


TIME 


8 byte character string designating 




(hour, minute, and second) 


HMESTAMP 


26 byte character string designating 




(year, month, day, hour, minute, second, 




and microsecond) 


TABLE 3 


ODL to SQL Data Type Mapping 


ODL Type 


SQL Type 


long 


CHAR(n), INTEGER, REAL, FLOAT, 




DECIMALfos) 


unsigned long 


CHAR(n), INTEGER, REAL, FLOAT, 




DECrMAL(p,s) 



short 

unsigned short 

10 float 
double 
char 
boolean 
octet 

15 

struct 



cnum 

sequence<type t 
n> 

20 string<n> 

array 
interface 



CHAR(n), SMALLINT, INTEGER, REAL, 

FLOAT, DECIMAL(p,s) 

CHAR(n), SMALUNT, INTEGER, REAL, 

FLOAT, DECIMAL(p,$) 

CHAR(n), REAL, FLOAT, DECIMAL^) 

CHAR(n), FLOAT, DEOMAL(p,s) 

CHAR(n), SMALUNT, INTEGER 

CHAR(n), SMALLINT, INTEGER 

CHAR(n), SMALUNT, INTEGER, REAL, 

FLOAT, DECtMAL(p,s) 

BLOB 

BLOB 

BLOB 

CHAR(n), SMALUNT 
BLOB 

CHAK(n), VARCHAR(n), LONG 

VARCHAR, BLOB 

BLOB 

BLOB, user defined 
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TABLE 4 



SQL Type 



SQL to ODL Data Type Mapping 
ODL Type 



30 



35 



50 
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CHAR(n) 


any, 5cqucncc<char^i>, string<n> t 




array 


VARCHAR(n) 


any, sequence<char,n>, string<D>, 




anay 


LONG VARCHAR 


any, sequence<char^>, string<n>, 




array 


GRAPHiqn) 


any, sequence4char^>, string<n>, 




amy 


VARGRAFHIC(n) 


any, scquencecchar^, strmg<n>, 




array 


LONG VARGRAPMC 


any, sequence<char,n>, string<a>, 




array 


BLOB 


any, scqucnce<char4]>, string<n>, 




array 


SMALLINT 


long, unsigned long, short, n™ig™n 




short, float, double, any, string<n> 


INTEGER 


long, unsigned long, float, double, any, 




string<li> 


REAL 


float, double, any, string<n> 


FLOAT 


double, any, string<n> 


DECIMAL(p ( s) 


float, double, any, string<o> 


DATE 


string<n> 


TIME 


string<n> 


TTMESTAMP 


string<n> 


TABLES 


Default SQL to ODL Data Type Mapping 


SQL Type 


ODL Type 



CHAR(n) 

VARCHAR(n) 

LONG VARCHAR 

GRAPHIC(n) 

VARGRAPHIC(n) 

LONG VARGRAPHIC 

BLOB 

SMALUNT 

INTEGER 

REAL 

FLOAT 

DEOMAL(p,6) 



string<n> 

string<n> 

string<d> 

string <n> 

string<n> 

string<n> 

string<n> 

short 

long 

float 

double 

double 
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TABLE 5-continued 



TABLE 8 



Default SQL to ODL Data Type Mapping 



SQL Type 


ODL Type 


DATE 


string<10> 


TIME 


5tring<8> 


TIME STAMP string<26> 


TABLE 6 


Default ODL to SQL Data Type Mapping 


ODL Type 


SQL Type 


long 


INTEGER 


unsigned bog 


INTEGER 


skirt 


SMALLENfT 


unsigned short 


SMALLLNT 


float 


FLOAT 


double 


FLOAT 


char 


CHAR(1) 


boolean 


SMALUNT 


octet 


CHAR(l) 


string<n> 


CHAR(n) if n is specified and n<=254. 




VARCHAR(n) if n is specified and rK=4000. 




LONGVAR if n is not specified or if n>4000. 


any 


BLOB 


struct 


BLOB 


union 


BLOB 




SMAIUNT 


sequence<type, 


BLOB 


n> 




array 


BLOB 


interface 


BLOB 



TABLE 7 



IMS Hierarchial Data Types 



IMS Hierarchial Type Description 



10 



15 



25 
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pd numeric packed decimal 

zd numeric zoned *fr?ima1 

is numeric integer abort, two bytes bog 

iJ number integer long, four bytes long 

id numeric integer double, eight bytes long 

fs numeric internal float number, four bytes long 

fd numeric internal float double, eight bytes long 

cf numeric external float double, language 

dependent 

ne character numeric edited, numeric (zoned decimal) 

with inserted character "0" or V or 

blank character 
aa character alphabetic, letter 

an character alphanumeric, letter and numeric 

ce character alphanumeric edited, alphanumeric (zoned 

decimal) with inserted character "0" or 

V or blank character 
cc character SBCS (single byte character set) 

character 

cb character character block data item, the first two 

bytes is length of block to indicate how 
many SBCS bytes will follow 

gg character DBCS (double byte character set) 

character 

xb hexadecimal hexadecimal block data item, the first 

two bytes is length of block to indicate 
how many bytes follow 

id hexadecimal eight-bit hexadecimal item 
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Default Mapping Between ODL and IMS Hierarchial Data Types 
Default ODL to IMS Hierarchial Data Type Mapping 



ODL Type 


IMS Hierarchial Data Type 


long 


il 


unsigned long 


il 


short 


is 


unsigned short 


is 


float 


fc 


double 


fd 


char 


cc 


boolean 


is 


octet 


xd 


string<n> 


cb, fixed size of n SBCS characters (one 




segment only) 


string 


cb, variable length of SBCS characters 




(one segment only) 


any 


xb variable length 


struct 


xb variable length 


union 


xb variable length 


enum 


is 


sequence<rype, n> xb variable length 


array 


xb variable length (one segment only) 


interface 


xb variable length (one segment only) 


Default IMS Hierarchial Data Type to ODL Mapping 


IMS Hierarchial 




Data Type 


ODL Type 


xd 


octet 


cc 


char 


Pd 


long 


zd 


long 


is 


short 


U 


long 


id 


double 


fs 


float 


fd 


double 


ef 


string<n> 


88 


string>n> 


TABLE 9 




Allowed Mapping Between ODL and 




IMS Hierarchial Data Types 


Allowed ODL to IMS Hierarchial Data Type Mapping 


ODL Type 


IMS Hierarchial Data Type 



50 long il,pd,zd 
unsigned long il, pd, zd 

short is, pd, zd 

unsigned short is, pd, zd 

float fc 
double fd 
char cc, is, H 

boolean is 
octet xd, is 

string<n> cb, fixed size of n SBCS characters (one 

segment only) 

cb, variable length of SBCS characters 
(one segment only) 
xb variable length 
xb variable length 
xb variable length 
is, cc£n) 

sequencectype, n> xb variable length 

array xb variable length (one segment only) 

interface xb variable length (one segment only) 



string 

any 

struct 

union 
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TABLE 9-continued 

Allowed Mapping Between ODL and 
IMS Hierarchial Data Types 

Allowed IMS Hierarchial Data Type to ODL Mapping 

IMS Hierarchial 



Data Type 


ODL Type 


id 


octet 


cc 


char 


Pd 


long, short 


zd 


long, short 


is 


short, long 


il 


long 


id 


double 


fe 


float 


ft 


double 


ef 


string<U> 


$$ 


6tring<n> 



We claim: 

1. A system for mapping objects to a data store, said 
system comprising: 

a first graphical user interface for mapping an object 

schema to a data store schema; 
a data structure for embodying said mapping, said data 

structure supporting said first graphical user interface 

and supporting a run-time access; 
a high level language generator for generating, from said 

data structure, a high level language representing said 

mapping; 

a parser for parsing said high level language into said data 
structure; and 

a translator for creating from said data structure and 
displaying said first graphical user interface represen- 
tation of said mapping. 

2. A system for mapping and accessing objects in data 
stores, said system comprising: 

graphical user interface for defining a mapping between 
an object schema and a data store schema in a high 
level language; 

a first graphical user interface for mapping said object 

schema to said data store schema; 
a data structure for embodying said mapping, said data 

structure supporting said first graphical user interface 

and supporting a run-time access; 
high level language generator for generating, from said 

data structure, said high level language representing 

said mapping; 

a parser for parsing said high level language into said data 
structure; 

a translator for creating said first user interface represen- 
tation of said mapping from said data structure; 

a second user interface, dependent upon an application 
programming interface, for accessing object data from 
said data store; 

said application prograrnming interface, independent of 
said second user interface, for accessing object data 
from said data store; 

a run-time component executing said application pro- 
gramming interface and implementing said object data 
access from said data store; 

a data store access for said run-time component to utilize 
said data structure embodying said mapping definition 
in accessing said objects from said data store; and 
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a generator for generating, from said data structure, an 

object oriented programrning language and data access 

language for deleting, adding, retrieving, and updating 

objects from said data store. 
5 3. A method of mapping objects to a data store, said 
method comprising the steps of: 
mapping an object schema to a data store schema via a 

first graphical user interface; 
embodying said mapping in a data structure supporting 
10 said first graphical user interface and supporting a 

run-time access; 
generating, from said data structure, a high level language 

representing said mapping; 
parsing said high level language into said data structure; 

and 

creating from said data structure and displaying said first 
graphical user interface representation of said mapping. 

4. A method of mapping and accessing objects in data 
l0 stores, said method comprising the steps of: 

defining a mapping between an object schema and a data 
store schema in a high level language via a graphical 
user interface; 

mapping said object schema to said data store schema via 
25 a first graphical user interface; 

embodying said mapping in a data structure supporting 
said first graphical user interface and supporting a 
run-time access; 

generating, from said data structure, said high level lan- 
30 guage representing said mapping; 

parsing said high level language into said data structure; 

creating said first user interface representation of said 
mapping from said data structure; 

accessing object data from said data store via a second 
user interface, dependent upon an application program- 
ming interface; 

accessing object data from said data store via said appli- 
cation prograrnming interface, independent of said sec- 
^ ond user interface; 

implementing said object data access from said data store 
via a run-time component executing said application 
programming interface; 

accessing said objects from said data store by said run- 
45 time component utilizing said data structure embody- 
ing said mapping definition; and 

generating, from said data structure, an object oriented 
programming language and data access language for 
deleting, adding, retrieving, and updating objects from 
so said data store. 

5. An article of manufacture for use in a computer system 
for mapping objects to a data store, said article of manu- 
facture comprising a computer-readable storage medium 
having a computer program embodied in said medium which 

53 causes the computer system to: 

map an object schema to a data store schema via a first 

graphical user interface; 
embody said mapping in a data structure supporting said 
first graphical user interface and supporting a run-time 
go access; 

generate, from said data structure, a high level language 

representing said mapping; 
parse said high level language into said data structure; and 
create from said data structure and display said first 
65 graphical user interface representation of said mapping. 

6. An article of manufacture for use in a computer system 
for mapping objects to a data store, said article of manu- 
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facture comprising a computer-readable storage medium 
having a computer program embodied in said medium which 
causes the computer system to: 
define a mapping between an object schema and a data 
store schema in a high level language via a graphical 5 
user interface; 
map said object schema to said data store schema via a 

first graphical user interface for; 
embody said mapping in a data structure supporting said 
first graphical user interface and supporting a run-time 
access; 

generate, from said data structure, said high level lan- 
guage representing said mapping; 
parse said high level language into said data structure; 15 
create said first user interface representation of said 
mapping from said data structure; 
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access object data from said data store via a second user 
interface, dependent upon an application programming 
interface; 

access object data from said data store via said application 
programming interface, independent of said second 
user interface; 

implement said object data access from said data store via 
a run-time component executing said application pro- 
gramming interface; 

access said objects from said data stare by said run-time 
component utilizing said data structure embodying said 
mapping definition; and 

generate, from said data structure, an object oriented 
programming language and data access language for 
deleting, adding, retrieving, and updating objects from 
said data store. 
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